Zum Netzwerk-Änderungsmanagement gehören fünf Grundprinzipien, etwa Risikoanalyse und Peer-Review. Damit lassen sich fehlgeschlagene Netzwerkänderungen und -ausfälle minimieren.
Beim Netzwerk-Change-Management oder Netzwerk-Änderungsmanagement handelt es sich um einen Prozess, der das Risiko einer fehlgeschlagenen Änderung reduzieren soll. Dieser Prozess ist mit mehreren Schritten verbunden, die erfolgreiche Änderungen sicherstellen. Aber wie funktioniert jeder einzelne Schritt?
In der Luftfahrt nutzen die Piloten klar definierte Prozesse, um ein sicheres Fliegen zu gewährleisten. Ähnlich können Networking-Teams definierte Prozesse nutzen, um das Risiko fehlgeschlagener Netzwerkänderungen, die ungeplante Ausfälle verursachen, zu reduzieren. Dennoch stellen Organisationen gelegentlich fest, dass Änderungen nicht wie geplant verlaufen, sondern stattdessen zu einem Ausfall führen. Einige Probleme sind Folge eines Prozessfehlers, während sich andere auf nicht offensichtliche Ergebnisse von komplexen Konfigurationen zurückführen lassen.
Der Prozess für das Netzwerk-Change-Management basiert auf der Anwendung mehrerer grundlegender Funktionsprinzipien, unter anderem:
Netzwerkteams sind verantwortlich für das Erstellen der Änderungsdetails: neue Konfigurationen, Informationen und Dokumentation der Geräteverbindungen. Das geschieht vor dem Change-Management-Prozess. Ein wertvoller Leitfaden für das Netzwerk-Change-Management ist das White Paper von Cisco mit dem Titel Change Management: Best Practices (PDF).
Umfang und Risikoanalyse
Der erste Schritt beim Netzwerk-Change-Management sollte sein, den Umfang einer beabsichtigten Änderung zu evaluieren. Ermitteln Sie, welche Services betroffen sein könnten und wer diese Services nutzt. Der Begriff Blast Radius wird üblicherweise verwendet, um den Umfang der Auswirkungen zu beschreiben, die eine Änderung mit sich bringen kann, einschließlich der negativen Folgen.
IT-Teams sollten den Umfang anhand der folgenden zwei Faktoren messen:
Anzahl der Endpunkte, die von einer Änderung betroffen sind.
Relevanz der Services, auf die sich eine Änderung möglicherweise auswirkt.
Nachdem die IT-Teams den Umfang festgestellt haben, sollten sie eine Risikobewertung vornehmen. Handelt es sich um eine Änderung, die bereits mehrfach in der Vergangenheit durchgeführt wurde und mit der man hinlänglich vertraut ist? Läuft sie vollständig automatisiert ab, oder besteht die Möglichkeit, dass es aufgrund menschlichen Fehlverhaltens zu unerwarteten Ergebnissen kommt? Ist die beteiligte Technologie hinreichend bekannt, oder besteht die Möglichkeit, dass etwas Unerwartetes passiert?
Der Umfang einer Änderung schlägt sich im Risiko nieder. Eine Änderung der Infrastruktur, auf der wichtige Geschäftsprozesse laufen, wird für das Unternehmen ein höheres Risiko bedeuten als eine Änderung bei einem kleinen Filialstandort.
Netzwerkteams können einen Risikofaktorrechner nutzen, der Schlüsselparametern bestimmte Werte zuordnet. Einen Risikorechner können Sie einfach selbst erstellen, indem Sie den Durchschnitt der Werte aus den unten stehenden Beispielparametern ermitteln.
Werden die Auswirkungen für Kunden sichtbar sein? (Nein = 1, Ja = 10)
Wie viele Kunden könnten betroffen sein? (Wert zwischen 1 und 10)
Wie wichtig sind die Services innerhalb des Umfangs? (Wert zwischen 1 und 10)
Wurde diese Änderung bereits erfolgreich in der Vergangenheit implementiert? (Ja = 1, Nein = 10)
Läuft die Änderung automatisiert ab? (Wert zwischen 1 und 10, je nach Grad der Automatisierung)
Lässt sich die Änderung vor der Implementierung ausgiebig testen? (Ja = 1, Nein = 10)
Ist die Dokumentation des Anbieters klar und eindeutig? (Wert zwischen 1 und 10)
Ist das Peer-Review gründlich, und hat es etwaige Probleme offengelegt? (Wert zwischen 1 und 10)
Je größer das Risiko, desto sorgfältiger und vorsichtiger müssen Teams während des restlichen Change-Management-Prozesses sein.
Abbildung 1: Befolgen Sie diese Schritte beim Netzwerk-Change-Management, um erfolgreiche Netzwerkänderungen sicherzustellen.
Peer-Review
Im nächsten Schritt geht es darum, ein Peer-Review durchzuführen. Obwohl Teams diesen Schritt vor der Risikoanalyse vornehmen können, ist es besser, den ermittelten Risikograd für ein eingehendes Peer-Review zu nutzen. Auch wenn alle Peer-Reviews vergleichbar gründlich sein sollten, dürften routinemäßige Änderungen – zum Beispiel an Access Control Lists (ACL) oder virtuellen LANs – eher flüchtig geprüft werden. Automatisiertes Testen und Deployment von routinemäßigen Änderungen kann dazu beitragen, das Risiko von oberflächlichen Peer-Reviews zu verringern.
Interne Mitarbeiter, die mit dem Netzwerk vertraut sind, werden die meisten Peer-Reviews durchführen. Wenn eine Änderung aus dem Rahmen fällt, ist es jedoch sinnvoll, dass ein Experte des Netzwerkausrüsters das Review vornimmt. Die Reviews sollten an die Phase der Risikoanalyse anknüpfen und die technischen Risikomaßnahmen gegebenenfalls aktualisieren, etwa indem sie angeben, ob Tests und Dokumentation ausreichen.
Pre-Deployment-Tests und -Validierung
Idealerweise müssten alle Änderungen eine Pre-Deployment-Test- und -Validierungsphase durchlaufen. Die Automation von sich wiederholenden Änderungen mit geringem Risiko kann verhindern, dass Änderungen nicht getestet werden, die Teams als risikoarm einschätzen. Je größer der Umfang und das Risiko, desto wichtiger ist es natürlich, die beabsichtigte Änderung ordnungsgemäß zu testen und zu validieren.
Die starke Verbreitung von virtuellen Router- und Switch-OS-Instanzen erleichtert den automatisierten Aufbau von Netzwerktopologien zu Testzwecken ohne teure Hardwareinvestitionen. Die IT-Abteilung muss zunächst für die notwendige Automation sorgen, um die virtuelle Netzwerktopologie zu erstellen, und sie dann wieder beseitigen, wenn die Tests erfolgreich abgeschlossen sind.
Pre-Deployment-Tests beinhalten etliche Schritte, die IT-Teams befolgen sollten, um eine beabsichtigte Änderung zu evaluieren:
Überprüfen Sie, ob das Testnetzwerk aktuell vor der Änderung so funktioniert wie vorgesehen.
Implementieren Sie die Änderung in einer Testinfrastruktur, um zu bestätigen, dass die Änderung zum gewünschten Endzustand führt. Die IT-Abteilung sollte automatisierte Prozesse nutzen, um menschliche Fehler auszuschließen und die Zeit für die Validierung der Änderung zu reduzieren. Wenn die Validierung in der Testumgebung fehlschlägt, stellen Sie die Ursache fest. Ist sie fehlgeschlagen, weil die Änderung falsch war oder weil das Testnetzwerk das echte Netzwerk nicht genau abbildet?
Testen Sie den Backout-Change-Prozess, so dass es einfach ist, zum vorherigen Zustand zurückzukehren, falls etwas schiefläuft. Der Backout Change sollte das Netzwerk wieder in den ursprünglichen Zustand bringen, was Teams überprüfen können, indem sie Schritt 1 wiederholen.
Implementierung und Testen
Das Deployment sowie Post-Deployment-Tests und -Validierung sollten dem gleichen Prozess folgen wie in Schritt 1 und 2 der Pre-Deployment-Tests. Wenn die Teams ihre Aufgabe bei Pre-Deployment-Tests und -Validierung gut erledigt haben, sollte nichts Unerwartetes passieren. Falls die Post-Change-Tests ein unerwartetes Problem erkennen, sollten die Teams die Änderung zurücknehmen und überprüfen, ob die Wiederherstellung der Services geklappt hat.
Die Prinzipien für ein gutes Netzwerk-Change-Management geben die Richtung vor, um ungeplante Netzwerkausfälle aufgrund von fehlgeschlagenen Änderungen zu reduzieren.
Einige Netzwerkprotokolle werden nach Änderungen an großen Netzwerken mehr Zeit benötigen, um sich anzugleichen. Das bedeutet, der Post-Change-Verifizierungsprozess muss Verzögerungen oder Konvergenztests vorsehen, was für Pre-Deployment-Tests in einer kleinen Umgebung nicht nötig ist.
Fortschrittlichere Organisationen automatisieren Änderungen an der Netzwerkkonfiguration mit dem Ziel, zu einer DevOps-Kultur auf Basis von Infrastructure as Code zu migrieren. Der Zweck besteht darin, kontinuierliche Integrations- und Breitstellungstests sowie einen Deployment-Prozess für risikoarme Änderungen einzuführen.
Aktualisieren von Dokumentation und Netzwerkmanagement
Idealerweise werden die IT-Teams während der Change-Erstellung Dokumente anlegen und aktualisieren. Dadurch sind sie in der Lage, die Dokumentation und die Änderungen am Netzwerkmanagement zusammen mit den Details der Änderung zu überprüfen. Nachdem die Teams die Änderung implementiert und verifiziert haben, können sie die Dokumentationsänderungen in das Netzwerkdokumentationssystem übernehmen.
Vergessen Sie nicht, gegebenenfalls das Netzwerkmanagementsystem upzudaten. Die meisten Netzwerkmanagementsysteme verfügen über APIs, die es automatisierten Prozessen ermöglichen, die Änderungen vorzunehmen.
Wenn der Schritt für die Änderungsvalidierung automatisiert ist, lässt er sich in regelmäßige Netzwerkvalidierungs-Checks integrieren. Diese periodischen Überprüfungen können Fehler in hochredundanten und -resilienten Netzwerken erkennen. Im Laufe der Zeit wird die IT-Abteilung eine Bibliothek von Netzwerkvalidierungs-Checks aufbauen, die viele Teile des Netzwerks abdecken.
Die Prinzipien für ein gutes Netzwerk-Change-Management geben die Richtung vor, um ungeplante Netzwerkausfälle aufgrund von fehlgeschlagenen Änderungen zu reduzieren. Die IT-Abteilung sollte einen Prozess erarbeiten, der für ihre Organisation funktioniert, und sich dafür einsetzen, dass dieser Prozess hocheffizient ist.
