Un CCIE se fait licencier - Partie 1 - Même les CCIEs cassent des choses

L'année dernière, j'ai fêté mes 20 ans de certification CCIE. Personne ne m'a organisé de fête, il n'y a pas eu de défilé, et si je n'avais pas récupéré l'e-mail dans mon dossier spam, je n'aurais même pas su que c'était arrivé. J'ai donc célébré le fait de ne plus avoir à payer $80 tous les deux ans à Cisco, puis j'ai téléchargé un logo CCIE Lifetime Emeritus pour l'apposer sur ma carte d'identité. Page LinkedIn (c'est chic, hein ?). L'obtention de cette certification m'a ouvert une foule de portes dans ma carrière, et j'en suis vraiment reconnaissant. Mais aujourd'hui, je n'ai plus besoin de me recertifier, ni de payer des cotisations, ni de faire quoi que ce soit, et pour tout cela, je suis également reconnaissante.

Être un expert en réseaux alors qu'il y avait une demande insatiable pour des compétences d'élite en matière de réseaux était certainement amusant. J'ai eu l'occasion de travailler dans un grand nombre d'endroits intéressants, j'ai fait le tour du monde en avion en classe économique, je me suis fait des amis formidables et, surtout, j'ai aidé un grand nombre de personnes.

Les réseaux ont évolué de façon spectaculaire au cours des 20 dernières années. J'ai l'impression d'être un dinosaure lorsque je regarde une nouvelle topologie de routage par segment ou lorsque j'essaie de comprendre les subtilités des dernières technologies de pointe. ASIC que tous les jeunes branchés utilisent. Mais plus les choses ont changé, plus elles sont restées les mêmes. Nous utilisons toujours les CLI, syslog et SNMP. Cela devrait faire réfléchir tout le monde, car la majorité des réseaux sont encore gérés avec des protocoles et des outils créés dans les années 70.  

- Clause de non-responsabilité : un paragraphe de marketing -

Récemment, j'ai travaillé sur certaines technologies qui est conçu pour permettre aux équipes DevOps de construire et d'exploiter des réseaux de centre de données et de périphérie avec leurs outils préférés, à savoir Kubernetes et le vaste monde des logiciels Cloud Native. Cette nouvelle approche passionnante de la mise en réseau éliminera-t-elle le besoin de CCIE ? C'est peu probable. Mais je n'ai pas besoin de faire quoi que ce soit pour y parvenir, cela se fera tout seul.  

- Marketing final -

Cette série d'articles décrira brièvement certains aspects de ma vie sur l'interface de programmation. Tout d'abord, je tiens à préciser que je vais parler des experts en réseaux comme des "CCIE". Si vous êtes un JNCIE ou simplement quelqu'un qui a gagné son propre badge d'honneur en menant le même style de vie, ce billet est pour vous. Je n'aime pas la religion des fournisseurs de réseaux, mais CCIE est le titre le plus court que je puisse utiliser pour décrire la crème de la crème des experts en réseaux.

Ignorant pour un moment la grande variété d'activités liées aux projets qui occupent la majeure partie de la journée (yawn), un CCIE fait essentiellement 3 choses :

• Rupture du réseau
• Corrige le réseau
• Mise en œuvre des déplacements, des ajouts et des modifications

(en espérant que ce ne soit pas tous les trois chaque jour !)

 

L'épisode où il casse le réseau

J'ai certainement cassé des réseaux. Si vous êtes un CCIE pendant un certain temps, vous l'avez fait aussi. C'est normal de hocher la tête maintenant, nous l'avons tous fait. Parfois, ce n'était pas de notre faute, parfois si. Avec le temps, ces expériences douloureuses se transforment en leçons dont nous tirons des enseignements, comme une cicatrice. Certaines personnes ont BEAUCOUP de cicatrices. Voici quelques-unes des miennes.

Une fois, j'ai mis hors service un grand bureau de presse parce que j'avais mal configuré une carte de routage pour essayer de distribuer le trafic sur deux liens de largeur de bande inégale. Les propriétaires de l'entreprise étaient bon marché et avaient acheté une liaison de 5MB et une liaison de "secours" de 1MB. À un moment donné, ils ont décidé d'utiliser le lien de secours pour un certain type de trafic et m'ont donc demandé d'établir une politique de routage des paquets sur le lien de 1 Mo. Dans le domaine des réseaux, chaque bit compte, et une plage d'adresses IP qui ne correspond pas au masque de bits peut vous causer beaucoup de tort. Dans mon cas, cela a eu pour effet d'orienter tout le trafic de la liaison 5MB vers la liaison 1MB. 5MB > 1MB évidemment et la liaison a été saturée en une seconde et voilà, adieu le bureau de presse de D.C.  Leçon : Ne laissez pas la direction vous forcer à mettre en péril un système majeur parce qu'il est bon marché. La redondance est synonyme de COÛT ÉGAL.

Une autre fois, j'ai causé un gros problème sur un grand site de commerce électronique avec mes premières tentatives d'automatisation. J'utilisais PERL (oui, je suis aussi vieux que ça) pour me connecter à un Cisco 5k via telnet (SSH n'était pas pris en charge sur le 5k) afin de recueillir quelques données télémétriques de base à partir d'une commande show. Si le script ne parvenait pas à se connecter, il réessayait simplement jusqu'à ce que la connexion soit établie, parce que de toute façon, qui a besoin d'un étranglement de la connexion ? Le 5k a été construit avant que l'on ne se préoccupe de la sécurité, donc si vous frappez le vty mgmt avec 10 tentatives de connexion d'affilée très rapidement, vous provoquez une panique du noyau. Joie. Naturellement, ce commutateur d'accès au campus était connecté au cœur de réseau via L2, et le cœur de réseau était également connecté à la partie frontale du site de commerce électronique. Spanning Tree peut être une chose vraiment ennuyeuse lorsqu'il fait son travail. Il m'est souvent arrivé de maudire le nom de Radia Perlman alors que le réseau était en panne (désolé Radia, je n'ai aucun moyen de compter toutes les fois où ton invention m'a magiquement sauvé la mise).  Leçon : Ne testez jamais une nouveauté, aussi inoffensive qu'elle puisse paraître, en production.

Ce dernier point est ce que certains appellent un "événement générateur de CV".

J'ai également raté des choses assez simples, comme débrancher un câble et le remettre en place. Parfois, si vous travaillez dans une armoire électrique encombrée, le câble passe dans le port suivant à droite, qui est bien sûr dans un VLAN différent. Et ce câble n'allait pas vers le bureau d'un utilisateur, il devait juste aller vers un serveur Microsoft Exchange, et c'est reparti pour un tour, adieu le bureau de presse à l'étranger. Les organisations de presse n'ont pas besoin d'un accès 24 heures sur 24 et 7 jours sur 7 à leur courrier électronique, n'est-ce pas ?  Leçon : Ne laissez personne vous obliger à prendre un risque personnel à cause d'une mauvaise planification. Leçon 2 : Ne branchez/débranchez pas les câbles si vous ne pouvez pas les voir facilement.

Si ce billet ressemble à une séance de thérapie freudienne, j'en suis désolé, mais en 20 ans, on a vraiment l'occasion de tout gâcher. Bon sang, il ne s'agit que de 3 erreurs, imaginez la longueur théorique de ce billet ! Certes, ces erreurs se sont produites à une autre époque, et certaines de ces entreprises étaient respectées pour la souplesse (lire : la rapidité) avec laquelle elles géraient leurs réseaux.

Quel est le point commun entre tous ces événements ? À part le fait que j'ai dû passer le reste de la journée caché dans une des armoires de câblage, dans chaque situation, j'ai eu affaire à un environnement créé par quelqu'un d'autre. Au niveau de l'interface utilisateur, ou en regardant le désordre du câblage, c'était comme si je voyageais dans le temps pour voir les décisions de conception exactes et la pensée de quelqu'un qui m'avait précédé des années auparavant. Je ne rejette pas la faute sur quelqu'un d'autre, j'ai certainement commis des erreurs, mais aucun de ces réseaux n'a été créé par moi. Ce sont ce que les ingénieurs réseau appellent des flocons de neige. Chacun d'entre eux est unique et personnalisé, avec un ensemble unique de comportements et de problèmes. Les CCIE détestent les flocons de neige des autres.

Offrir un cadeau d'anniversaire à un CCIE

Mais la mise en réseau est une question d'ordre, d'organisation et de déterminisme. La mise en réseau est un peu comme les Legos. Tout le monde sait comment utiliser les Legos. Ils ont une certaine sensation dans la main et s'emboîtent avec un clic spécifique qui vous permet de savoir si la connexion est bonne. Les Legos s'interconnectent de manière très précise, mais les options de connectivité sont si vastes qu'il est possible de les empiler dans un nombre infini de configurations.

Les CCIE n'aiment pas reprendre les problèmes de quelqu'un d'autre parce qu'il n'y a jamais assez de documentation pour les mettre à l'aise. Mais avec les Legos, vous n'avez pas besoin de documentation. Les briques sont des pièces bien définies qui s'interconnectent d'une manière très précise. Et lorsque vous construisez un grand jeu, le manuel vous montre exactement comment l'assembler pour obtenir le résultat annoncé sur le devant de la boîte. N'achetez donc pas un flocon de neige au CCIE de votre entourage pour son anniversaire.  

De nombreuses entreprises de réseaux vendent des Legos. Certaines veulent encore que vous utilisiez le CLI pour assembler leurs Legos. Cela vous semble-t-il très "Lego" ? Nous (tous les acteurs de l'industrie des réseaux) devons faire beaucoup mieux pour offrir aux constructeurs de réseaux une expérience plus conviviale et plus proche du consommateur. Nous devons produire des blocs de construction polis, parfaitement adaptés et fonctionnels afin que davantage de personnes puissent les assembler, les déplacer, les modifier et les interconnecter au reste de notre ville Lego. Nous devons fournir de meilleurs produits, avec plus d'intelligence intégrée, afin que les utilisateurs finaux obtiennent des résultats plus déterminés.  

Et, avec un peu de chance, beaucoup moins d'incidents dus à des ingénieurs innocents qui s'introduisent dans le réseau.

P.S. La prochaine fois, je parlerai des choses que j'ai faites et qui ont sauvé la journée. Youpi