Il était environ 2 heures du matin lorsque nous avons décidé de faire une pause et de nous diriger vers la salle de conférence où il y avait des restes de pizza de plus tôt dans la journée. J'adore la bonne pizza, mais même une bonne pizza n'est pas si bonne au milieu de la nuit lorsqu'un rafraîchissement du réseau ne se passe pas bien.
Tous les commutateurs d'accès dans la zone du bureau principal ont été échangés la semaine précédente, et cette partie de ce projet de rafraîchissement des commutateurs s'est déroulée sans accroc. Ce soir, cependant, nous travaillions sur l'échange d'appareils dans l'usine de fabrication principale, où nous avons trouvé surprise après surprise. Ce qui aurait dû être un simple échange de commutateurs d'accès simples s'est transformé en une nuit de chagrin et d'héroïsme.
En m'arrêtant pendant vingt minutes pour prendre une tranche de pizza et boire un soda, j'ai eu l'occasion de parler à mes collègues et à notre client qui nous a donné la documentation du réseau en premier lieu. Nous n'étions pas carrément en colère l'un contre l'autre, mais j'ai senti le début d'un subtil jeu de blâme.
Le projet n'avait pas une portée très différente des précédents projets d'actualisation du réseau que j'ai réalisés, donc ce n'était pas la technologie réelle qui était si frustrante. Ce qui était si difficile à digérer à côté de ce qui aurait dû être une excellente collation de minuit, c'était de réaliser à quel point ce projet était mal planifié en raison d'un manque de qualité documentation réseau et découverte du réseau.
Nous n'étions pas aux prises avec la complexité de la configuration d'une douzaine de superpositions, et nous n'étions pas aux prises avec la recherche d'une solution de contournement à un bogue logiciel. Au lieu de cela, nous étions aux prises avec une planification et des processus médiocres.
En saisissant une deuxième tranche, j'ai demandé à mon client s'il pouvait penser à d'autres interrupteurs cachés dans des plafonds suspendus ou des racks muraux sans papiers. Il ne pouvait pas, alors il a suggéré que nous allions nous promener pour nous en assurer. Je n'aimais pas entendre cela, compte tenu de l'heure qu'il était, mais je n'aimais pas non plus entendre pour la première fois qu'ils utilisaient un système VoIP sur téléphone sans fil qui nécessitait des politiques QoS personnalisées pour fonctionner efficacement dans leur usine de fabrication.
Nous avons commencé notre quête, laissant quelques ingénieurs derrière nous pour se détendre et manger la dernière tarte au pepperoni tiède. Mon client et moi avons eu un tête-à-tête à propos de ces problèmes, ce qui m'a vraiment aidé à créer un sentiment d'urgence en lui.
Vous voyez, le centre de contrôle générait suffisamment de trafic pour saturer la liaison de tronc de 1 gigaoctet vers le centre de données, mais la conception n'appelait pas de canal de port ou à tout le moins une seule liaison de tronc de 10 gigaoctets. Cela aurait dû être une évidence dans tout cycle d'actualisation du réseau, mais ni le client ni nos préventes n'ont effectué d'analyse de base du trafic.
De plus, j'ai expliqué que puisque nous écrivions une politique QoS personnalisée à la volée ce soir, il n'y aurait aucun moyen de vraiment valider son efficacité jusqu'au lendemain lorsque le réseau serait sous charge. Ce que nous aurions dû faire, c'est simuler le réseau autant que possible et pousser la configuration par programmation. Malheureusement, nous allions devoir toucher chaque nouveau commutateur un par un pour ajouter la configuration QoS et la politique de service pertinentes à chaque port de jonction.
Je me souviens qu'il a hoché la tête en signe d'accord et proposé d'aider à annuler les changements de ce soir afin que nous puissions nous regrouper le lendemain. Le seul problème avec cela, ai-je expliqué, était qu'il était déjà plus de 2 heures du matin et que tout ce que nous devions faire pour revenir en arrière serait entièrement manuel. Je ne savais pas si nous avions assez de temps.
Nous avons choisi d'aller de l'avant, mais nous avons décidé de travailler toute la nuit et jusqu'en fin de matinée. Vers 4 heures du matin, mon chef de projet était sur place avec d'énormes quantités de café et, heureusement, il a fait de son mieux pour rester à l'écart. J'en étais reconnaissant, car à ce moment-là, nous n'avions pas encore tous pris notre second souffle.
Mon équipe a trouvé plusieurs autres commutateurs malveillants qu'ils ont intégrés dans la nouvelle conception car le client n'en avait pas acheté suffisamment pour les remplacer. J'ai recherché la documentation sur le système téléphonique afin de comprendre la politique de qualité de service, mais ma première pensée n'était pas de prendre la peine de voir comment se déroulaient les appels téléphoniques. Cependant, même au milieu de la nuit sans charge sur le réseau, nos appels de test étaient très médiocres.
Nous travaillions avec un déficit d'information. L'absence d'une découverte de réseau décente et d'une compréhension du fonctionnement des applications sur le réseau nous a empêchés d'effectuer ce qui aurait dû être une simple actualisation des périphériques réseau. Nous n'avons pas pris en compte plusieurs considérations importantes avant d'entreprendre ce projet.
Notre première étape aurait dû être de rassembler des informations sur le réseau par le biais de la documentation et d'une découverte du réseau. Il ne suffit pas de compter le nombre d'interrupteurs à remplacer.
NetBrain résout cela avec dynamique cartes du réseau qui créent une documentation précise en quelques minutes. Aucune équipe d'ingénieurs n'est nécessaire pour explorer manuellement le réseau pour la découverte des actifs et de la topologie.
Gardez à l'esprit qu'il s'agit bien plus que de créer une feuille de calcul d'inventaire. Une actualisation réussie des périphériques réseau commence par l'identification des plates-formes et des versions logicielles afin que les fonctionnalités appropriées puissent être planifiées dans la nouvelle conception. NetBrain capture ces données par programmation et à la demande, ce qui aurait été extrêmement utile pour un ingénieur frustré comme moi à 2 heures du matin.
Deuxièmement, nous avions besoin d'un mécanisme pour évaluer les fonctionnalités et la syntaxe du nouvel équipement. Par exemple, la mise à niveau des commutateurs de 1 gigaoctets à 10 gigaoctets peut avoir des ramifications sur Spanning Tree ou les décisions de routage, et cela doit être testé et évalué avant le début de la minuterie de la fenêtre de changement.
Dans mon cas, j'avais besoin de pouvoir évaluer la configuration QoS à la volée et rapidement. Certes, il est extrêmement difficile de tester la configuration QoS sans que le réseau ne soit sous charge, mais il est tout aussi important de tester l'implémentation réelle de la syntaxe en raison de ses différences d'une plate-forme à l'autre.
Et troisièmement, nous n'avions aucun moyen de toucher par programmation un grand nombre d'appareils. Être capable de le faire par programmation à la fois dans le déploiement de la configuration et dans la restauration de la configuration peut transformer une actualisation du réseau d'un scénario tout-en-un en un projet gérable qu'un seul ingénieur pourrait gérer.
NetBrain ne peut pas mettre en rack tous vos commutateurs pour vous, mais il répond au besoin d'une découverte dynamique du réseau, d'une documentation à la demande et d'une programmabilité accrue.
Ce projet d'actualisation du réseau de l'organisation de fabrication a fini par être un succès, mais nous avons travaillé pendant 30 heures d'affilée avec une équipe de cinq ingénieurs pour y parvenir. Le café a aidé, la pizza a aidé, mais avoir les bons outils pour obtenir les informations dont nous avions besoin à l'avance et à la demande, c'est ce qui aurait sauvé la situation.