Un CCIE se fait licencier - Partie 2 - "Il est difficile de licencier un CCIE".

Il est en fait difficile de licencier un CCIE. Et non, il ne s'agit pas d'une menace voilée à l'égard de mon patron. Mettons-nous un instant à la place de la direction. Le réseau est une boîte noire effrayante, il ne suffit pas d'y brancher un moniteur VGA pour voir ce qui s'affiche à l'écran.  

Il existe un grand nombre d'outils et de systèmes de surveillance différents, dont aucun ne fonctionne dans 100% des cas. Lorsque le réseau fait vraiment quelque chose d'inhabituel ou se comporte mal d'une manière ou d'une autre, la réponse n'est jamais claire. Le problème ne peut être discerné qu'en examinant des fichiers de log d'apparence loufoque, ou pire encore. Si vous êtes unSi vous vous demandez ce qu'il y a de pire qu'un fichier journal, c'est que vous n'avez manifestement jamais eu à lire une trace de paquet.

Pour ceux qui nous rejoignent, il s'agit de la deuxième partie de cette série. Dans ce billet, j'appellerai tous les experts en réseaux des CCIE. Si vous êtes un CCIE, ou un JNCIE, ou tout autre type d'IE, ou simplement un architecte/ingénieur réseau de premier plan, lorsque je parle des CCIE, je parle de vous ! C'est une grande tente, venez nous rejoindre...

Revenons donc à ce que j'ai dit la dernière fois. Un CCIE fait essentiellement ces 4 choses :

• Casse le réseau - Mon dernier message
• Corrige le réseau - Ce poste
• Déplacements/Ajouts/Modifications
• Gestion de projet

Si nous nous replaçons dans la peau de notre manager, nous considérons nos employés CCIE comme un atout très précieux. Beaucoup d'entreprises ont au plus un CCIE, quelques-unes en ont plus d'un, et la grande majorité des entreprises n'en ont aucun. Il est difficile de trouver des CCIE, de les recruter, de les employer et de les garder. Ils peuvent être assez chers et parfois un peu bizarres dans leurs relations. Quels sont donc les avantages pour un chef d'entreprise qui dispose d'un CCIE dans son équipe ?

Les CCIE (en plus de leur travail réel) sont un peu comme une assurance. Ce sont les têtes pensantes de l'organisation informatique, les personnes à qui l'on s'adresse lorsque les choses sont VRAIMENT cassées. Ils ne peuvent pas résoudre tous les problèmes liés à la couche applicative, mais ils peuvent au moins indiquer quel système ne fonctionne pas comme il le devrait. Ainsi, votre CCIE, éventuellement en lisant une capture de paquets, peut dire à votre organisation où se situe le problème. Quel serveur ne répond pas ? Et si les choses sont cassées et que vous n'avez pas de CCIE, quelles sont les options qui s'offrent à vous ?

• Appeler le fournisseur du réseau (ex. Cisco TAC, Juniper JTAC)
• Appelez votre fournisseur de services gérés
• Engagez un consultant en espérant qu'il ne soit pas trop occupé pour vous aider.
• Aller sur StackOverflow, ChatGPT, Discord
• Contactez votre divinité locale

Aucune de ces options n'est particulièrement bonne. Chacune d'entre elles nécessite un certain délai, éventuellement l'échange d'un peu d'argent (ou, dans le cas de la divinité, de votre premier né), et elles exigent toutes que quelqu'un d'autre se mette au diapason de votre environnement. Si votre entreprise est en panne et que vous devez attendre qu'un consultant comprenne votre problème, accède à vos systèmes et procède au dépannage, disons que ces minutes/heures/jours vont passer comme une éternité. Par conséquent, si votre entreprise est si grande et si importante que vous ne pouvez tolérer ce délai, vous engagez un CCIE. Le fait d'avoir cette personne au bout du couloir de votre bureau est votre propre forme d'assurance. C'est le filet de sécurité. La responsabilité s'arrête là.

Mais que se passe-t-il si le CCIE ne peut pas résoudre le problème ? Tout d'abord, cela le pousserait dans le puits mental du syndrome de l'imposteur. Il y a toujours un problème qui peut déconcerter n'importe quel expert, y compris les CCIE. Heureusement, ils peuvent toujours contacter l'une des tierces parties mentionnées précédemment et, pendant qu'ils sont en attente, ils continuent à dépanner et à saisir des informations pour aider quelqu'un d'autre à comprendre l'origine du problème. Et s'ils font appel à une entité d'assistance à distance telle qu'un centre d'assistance technique (TAC), ils agissent en tant qu'experts à distance, en effectuant toutes les actions physiques nécessaires pour obtenir les informations permettant d'identifier le problème.

Tous les CCIE souffrent du syndrome de l'imposteur. Il y a toujours quelque chose que nous ne pouvons pas comprendre ou réparer, et bien que cela soit parfois déstabilisant, c'est une réalité lorsque nous utilisons un équipement construit par quelqu'un d'autre.

Dans mon dernier article, j'ai eu quelques moments de mea culpa (traduction : j'ai fait une erreur). Mais il y a eu des moments où je n'ai absolument pas souffert du syndrome de l'imposteur. Il y a eu des moments où j'ai sauvé la situation ou, comme il est écrit sur mon CV, il m'arrive de botter des fesses.

Brève histoire de Josh et de ses coups de pied au cul

Je me suis précipité au siège d'une entreprise mondiale de médias et de diffusion à 2 heures du matin alors que tout le réseau était en panne, et j'ai passé des heures à dépanner et à me faufiler dans le campus comme un bandit jusqu'à ce que je trouve un vieux commutateur poussiéreux dans un bureau de chauffage, de ventilation et de climatisation qui se trouvait 4 étages en dessous du niveau de la rue, au milieu de Manhattan. Le commutateur se trouvait dans une pièce où un gestionnaire d'installations surveillait la climatisation de tout un campus d'entreprise sur un petit écran, et lorsque j'ai fait irruption dans sa pièce à l'improviste à 4 heures du matin, que j'ai couru jusqu'au commutateur et que j'ai tiré l'un des câbles, j'ai eu l'impression d'assister à une scène du Seigneur des anneaux. Ce type (qui ne recevait manifestement jamais de visiteurs et qui semblait ne pas avoir beaucoup de soleil) était certainement effrayé par le fait que je pénètre dans son antre et que je m'attaque à son trésor. Quoi qu'il en soit, le réseau est revenu à la vie. Le réseau est revenu à la vie et j'ai lentement navigué vers la sortie des tunnels de vapeur. ÉNORME GAGNANT.  Leçon : En tant qu'expert, vous devez prendre le temps de visiter et d'inspecter visuellement chaque équipement, aussi éloigné soit-il.

J'ai un jour dépanné un Cisco 7206VXR en panne alors que j'étais en vacances via une connexion téléphonique irrégulière, en utilisant une personne totalement non qualifiée comme main d'œuvre dans le centre de données distant. Heureusement, j'ai une mémoire photographique, ce qui m'a permis de décrire l'emplacement exact de l'appareil, ainsi que l'endroit où trouver un câble auxiliaire et un dongle, et où se trouve le port de la console au milieu d'un nid de vieux câbles. Mon ami à distance a fait ses premières armes en construisant un chariot de réanimation et en se connectant à la console (je l'ai probablement marqué à vie) et une fois que nous avons su que l'appareil était accroché, nous l'avons redémarré. Le réseau a été rétabli. Sur la passerelle de conférence se trouvaient mon supérieur direct, le chef de service et le directeur d'une société récemment acquise qui possède plusieurs studios de cinéma. Ils ne tarissaient pas d'éloges. J'ai raccroché et je me suis offert une (autre) pina colada.  Leçon : Laissez des câbles de console supplémentaires partout où vous le pouvez.  Leçon 2 : Profitez de votre temps libre, vous le méritez.

Une fois, j'ai mis fin à un dépannage d'une semaine que quelqu'un avait effectué sur un Nexus 7k qui décidait sans discernement des paquets à transmettre. Je me suis rendu sur place pour aider un ingénieur débutant et il m'a fallu deux minutes pour identifier le problème. "Pourquoi le châssis est-il tordu ?" Quelques heures plus tard, il admet qu'ils l'ont fait tomber "juste une fois" pendant qu'ils le mettaient en place. La foule est en délire. Leçon : L'équipement tombé est probablement défectueux.

J'ai résolu à moi seul un problème qui provoquait des pannes sporadiques entre deux grandes entreprises de médias qui fusionnaient. Le super architecte réseau de l'autre société a décidé qu'il serait intéressant d'isoler les contrôles administratifs en plaçant deux SUP4 dans un seul 6509, chaque société en contrôlant un. MAUVAISE IDÉE.  Leçon : Les superviseurs redondants doivent avoir des configurations identiques.

J'ai évité à un important site de commerce électronique d'être mis hors service lors de la panne d'électricité sur la côte Est en 2003. J'étais à mon bureau lorsque les lumières se sont éteintes dans le bâtiment. Ma première pensée a été "Oh merde, j'espère que je n'ai pas fait ça", puis je suis passé à l'action en courant sur trois étages jusqu'à un centre de colocation pour vérifier ce qu'il était advenu de notre centre de données. Heureusement, le centre de colocation était équipé d'une batterie de secours et tout fonctionnait, mais dans un moment de clairvoyance, j'ai décidé de vérifier si nos commutateurs principaux étaient tous connectés au réseau électrique de secours, qui serait la seule source d'énergie dans moins de 5 minutes. J'ai remarqué que quelqu'un avait mal connecté les alimentations redondantes à un commutateur central. En ressemblant au Road Runner, j'ai trouvé un câble de remplacement et je l'ai inséré environ 3 secondes avant que l'alimentation ne passe de la batterie au générateur de secours. Si je n'avais pas fait cela, toute l'entreprise aurait été détruite. Leçon : Soyez proactif dans l'évaluation des scénarios de reprise après sinistre et testez tout fréquemment.

Ne construisez pas de flocons de neige

Mais tout le monde ne peut pas se permettre d'avoir un expert en réseau dans son équipe 24 heures sur 24 et 7 jours sur 7. C'est pourquoi il existe une multitude d'outils de surveillance, d'analyse et de dépannage des réseaux. Par ailleurs, le secteur a beaucoup évolué au cours des dix dernières années. Aujourd'hui, nous construisons des réseaux selon quelques modèles assez courants, et de nombreux produits mettent en œuvre les meilleures pratiques de conception par défaut. En fait, il est possible de concevoir un réseau en ligne et d'y intégrer toutes les techniques et optimisations utilisées par les principaux fournisseurs de services en nuage. Non seulement ces améliorations permettent d'éliminer les problèmes à l'avance, mais les topologies de réseau bien conçues et déterministes sont beaucoup plus faciles à dépanner si jamais vous en héritez.

Les CCIE ont-ils moins de valeur aujourd'hui ? Si votre réseau est en panne, la réponse est clairement NON, vous êtes susceptible de payer n'importe quelle somme d'argent pour le remettre en ligne. Mais le monde a beaucoup changé au cours des vingt dernières années. Nous n'utilisons plus vraiment une tonne de protocoles différents (RIP : DLSW, Appletalk, IPX/SPX, DECnet, Vines, etc.), et certaines topologies et conceptions de réseau se sont avérées être la meilleure solution technique pour certains cas d'utilisation (ex. Leaf-Spine Clos Fabric pour la connectivité des serveurs des centres de données). Cela signifie que les architectes construisent des unités de réseau reproductibles (et fiables), plutôt que quelque chose de bancal qui est difficile à dépanner. Et cela signifie que vous avez moins de chances d'avoir besoin d'un CCIE. Poursuivons notre discussion dans la partie 3.

Jusqu'à la prochaine fois !