Es war etwa 2 Uhr morgens, als wir beschlossen, aufzubrechen und in den Konferenzraum zu gehen, wo es noch Pizzareste von früher an diesem Tag gab. Ich liebe gute Pizza, aber selbst gute Pizza ist mitten in der Nacht nicht so toll, wenn eine Netzwerkaktualisierung nicht gut läuft.
Alle Zugangsschalter im Hauptbürobereich wurden in der Woche zuvor ausgetauscht, und dieser Teil dieses Schalteraktualisierungsprojekts verlief ohne Probleme. Heute Abend arbeiteten wir jedoch daran, Geräte in der Hauptproduktionsstätte auszutauschen, wo wir Überraschung nach Überraschung erlebten. Was ein einfacher Austausch einfacher Zugangsschalter hätte werden sollen, wurde zu einer Nacht voller Kummer und Heldentaten.
Ich hielt für zwanzig Minuten an, um mir ein Stück Pizza zu schnappen und etwas Limonade zu trinken, und hatte Gelegenheit, mich mit meinen Kollegen und unserem Kunden zu unterhalten, der uns überhaupt die Netzwerkdokumentation gegeben hatte. Wir waren nicht direkt wütend aufeinander, aber ich spürte die Anfänge eines subtilen Schuldzuweisungsspiels.
Das Projekt unterschied sich im Umfang nicht sehr von früheren Netzwerkaktualisierungsprojekten, die ich durchgeführt habe, also war es nicht die eigentliche Technologie, die so frustrierend war. Was so schwer zu verdauen war neben dem, was ein toller Mitternachtssnack hätte werden sollen, war die Erkenntnis, wie schlecht dieses Projekt aufgrund mangelnder Qualität geplant war Netzwerkdokumentation und Netzwerkerkennung.
Wir hatten nicht mit der Komplexität der Konfiguration eines Dutzend Overlays zu kämpfen, und wir hatten keine Probleme damit, einen Workaround für einen Softwarefehler zu finden. Stattdessen hatten wir mit schlechter Planung und Prozessen zu kämpfen.
Ich schnappte mir ein zweites Stück und fragte meinen Kunden, ob ihm weitere Schalter einfallen würden, die sich in abgehängten Decken oder undokumentierten Wandregalen verstecken. Das konnte er nicht, also schlug er vor, wir sollten einen Spaziergang machen, um sicherzugehen. Ich hörte das nicht gerne, wenn man bedenkt, wie spät es war, aber ich mochte es auch nicht, zum ersten Mal zu hören, dass sie ein VoIP-über-Wireless-Telefonsystem verwendeten, das benutzerdefinierte QoS-Richtlinien erforderte, um in ihrer Produktionsstätte effektiv zu funktionieren.
Wir begannen mit unserer Suche und ließen ein paar Ingenieure zurück, um sich zu entspannen und die letzte lauwarme Peperoni-Torte zu essen. Mein Kunde und ich sprachen über diese Probleme, was mir wirklich half, ein Gefühl der Dringlichkeit in ihm aufzubauen.
Sie sehen, das Kontrollzentrum generierte genug Datenverkehr, um die 1-Gig-Trunk-Verbindung zurück zum Rechenzentrum zu sättigen, aber das Design sah keinen Portkanal oder zumindest eine einzelne 10-Gig-Trunk-Verbindung vor. Dies hätte in jedem Netzwerkaktualisierungszyklus selbstverständlich sein sollen, aber weder der Kunde noch unsere Pre-Sales-Leute haben eine Grundverkehrsanalyse durchgeführt.
Außerdem erklärte ich, dass es, da wir heute Abend spontan eine benutzerdefinierte QoS-Richtlinie geschrieben haben, keine Möglichkeit gibt, ihre Wirksamkeit wirklich bis zum nächsten Tag zu validieren, wenn das Netzwerk unter Last steht. Wir hätten das Netzwerk so weit wie möglich simulieren und die Konfiguration programmgesteuert übertragen sollen. Leider mussten wir jeden neuen Switch einzeln anfassen, um jedem einzelnen Trunk-Port die relevante QoS-Konfiguration und Service-Richtlinie hinzuzufügen.
Ich erinnere mich, dass er zustimmend nickte und anbot, die Änderungen von heute Abend rückgängig zu machen, damit wir uns am nächsten Tag neu formieren konnten. Das einzige Problem dabei, erklärte ich, war, dass es bereits nach 2 Uhr morgens war und alles, was wir tun mussten, um zurückzusetzen, komplett manuell sein würde. Ich war mir nicht sicher, ob wir genug Zeit hatten.
Wir entschieden uns dafür, vorwärts zu gehen, aber wir entschieden uns dafür, die ganze Nacht und bis in den späten Morgen hinein zu arbeiten. Gegen 4 Uhr morgens war mein Projektmanager mit riesigen Mengen Kaffee vor Ort, und zum Glück tat er sein Bestes, uns aus dem Weg zu gehen. Dafür war ich dankbar, denn bis dahin hatten noch nicht alle von uns den zweiten Wind bekommen.
Mein Team fand mehrere weitere fehlerhafte Schalter, die sie in das neue Design integrierten, da der Kunde nicht genug gekauft hatte, um sie zu ersetzen. Ich habe die Dokumentation des Telefonsystems durchsucht, um die QoS-Richtlinien herauszufinden, aber mein erster Gedanke war, mich nicht darum zu kümmern und zu sehen, wie Telefonanrufe verlaufen. Aber selbst mitten in der Nacht ohne Netzlast waren unsere Testanrufe sehr schlecht.
Wir arbeiteten mit einem Informationsdefizit. Das Fehlen einer anständigen Netzwerkerkennung und das Fehlen eines Verständnisses dafür, wie Anwendungen im Netzwerk funktionierten, hinderte uns daran, eine einfache Netzwerkgeräteaktualisierung durchzuführen. Wir haben einige wichtige Überlegungen nicht berücksichtigt, bevor wir dieses Projekt in Angriff genommen haben.
Unser erster Schritt hätte sein sollen, Informationen über das Netzwerk durch Dokumentation und eine Netzwerkerkennung zu sammeln. Es reicht nicht aus, einfach die Anzahl der zu ersetzenden Schalter zu zählen.
NetBrain adressiert dies mit dynamisch Netzwerkkarten die in wenigen Minuten eine genaue Dokumentation erstellen. Es ist kein Team von Ingenieuren erforderlich, um das Netzwerk manuell zu crawlen, um Assets und Topologien zu erkennen.
Denken Sie daran, dass dies viel mehr ist als das Erstellen einer Bestandstabelle. Eine erfolgreiche Netzwerkgeräteaktualisierung beginnt mit der Identifizierung von Plattformen und Softwareversionen, damit die entsprechenden Funktionen im neuen Design eingeplant werden können. NetBrain erfasst diese Daten programmgesteuert und auf Abruf, was für einen frustrierten Ingenieur wie mich um 2 Uhr morgens äußerst nützlich gewesen wäre.
Zweitens brauchten wir einen Mechanismus, um Funktionen und Syntax der neuen Ausrüstung zu evaluieren. Beispielsweise kann das Upgrade von Switches von 1-Gig-Trunks auf 10-Gig-Trunks Auswirkungen auf Spanning Tree- oder Routing-Entscheidungen haben, und dies muss getestet und bewertet werden, bevor der Zeitgeber für das Änderungsfenster beginnt.
In meinem Fall brauchte ich die Möglichkeit, die QoS-Konfiguration spontan und schnell zu evaluieren. Zugegeben, es ist extrem schwierig, die QoS-Konfiguration zu testen, ohne dass das Netzwerk unter Last steht, aber es ist genauso wichtig, die tatsächliche Implementierung der Syntax zu testen, da sie sich von Plattform zu Plattform unterscheiden kann.
Und drittens hatten wir keine Möglichkeit, eine große Anzahl von Geräten programmgesteuert zu bearbeiten. Die Möglichkeit, dies programmgesteuert sowohl beim Bereitstellen der Konfiguration als auch beim Zurücksetzen der Konfiguration zu tun, kann eine Netzwerkaktualisierung von einem All-Hands-on-Deck-Szenario in ein überschaubares Projekt verwandeln, das ein einzelner Ingenieur bewältigen kann.
NetBrain kann nicht alle Ihre Switches für Sie zusammenstellen, aber es erfüllt den Bedarf an dynamischer Netzwerkerkennung, Dokumentation auf Abruf und verbesserter Programmierbarkeit.
Dieses Projekt zur Aktualisierung des Netzwerks der Fertigungsorganisation war am Ende erfolgreich, aber wir haben 30 Stunden am Stück mit einem Team von fünf Ingenieuren gearbeitet, um es zu verwirklichen. Kaffee hat geholfen, Pizza hat geholfen, aber die richtigen Tools zu haben, um die benötigten Informationen im Voraus und auf Abruf zu erhalten, hätte den Tag gerettet.