5 Grundsätze für das Netzwerk-Change-Management

1. 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:

1. Anzahl der Endpunkte, die von einer Änderung betroffen sind.
2. 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.

2. 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 Bereitstellen 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.

3. Tests und Validierung vor dem Einsatz

Idealerweise durchlaufen alle Änderungen vor der Bereitstellung eine Test- und Validierungsphase. Ziehen Sie in Betracht, sich wiederholende Aufgaben und Änderungen mit geringem Risiko zu automatisieren, um der Versuchung zu entgehen, Tests für Änderungen zu überspringen, die von den IT-Teams als risikoarm eingestuft werden. Je größer der Umfang und das Risiko, desto wichtiger ist es, die vorgeschlagene Ä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. Verwenden Sie Netzwerk-Labs und Sandboxes, um Automatisierungs-Workflows in einer virtuellen Netzwerktopologie zu erstellen, die Teams nach erfolgreichem Abschluss der Tests wieder entfernen können.

Die Tests vor der Bereitstellung umfassen mehrere Schritte, die IT-Teams befolgen sollten, um eine vorgeschlagene Änderung zu bewerten:

1. Überprüfen Sie, ob das Testnetzwerk aktuell vor der Änderung so funktioniert wie vorgesehen.
2. 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?
3. 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.

4. Implementierung und Testen

Die Tests und Validierungen vor und nach der Bereitstellung sollten nach demselben Verfahren wie in den Schritten 1 und 2 der Tests vor der Bereitstellung erfolgen. Wenn die Teams vor dem Einsatz gute Arbeit bei den Tests und der Validierung geleistet haben, sollte nichts Unerwartetes passieren. Wenn bei Tests nach der Änderung ein unerwartetes Problem festgestellt wird, sollten die Teammitglieder die Änderung rückgängig machen und die Wiederherstellung des Dienstes überprüfen.

Einige Netzwerkprotokolle benötigen nach Änderungen an großen Netzwerken mehr Zeit, um zu konvergieren. Daher sollte die Überprüfung nach der Änderung Verzögerungen oder Konvergenztests beinhalten, die bei Testläufen vor der Bereitstellung in einer kleinen Testumgebung nicht erforderlich sind.

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 Beeitstellungsprozess für risikoarme Änderungen einzuführen.

5. 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 Netzwerkvalidierungschecks 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 Netzwerkvalidierungschecks aufbauen, die viele Teile des Netzwerks abdecken.

Die Grundsätze 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.

Hinweis: Dieser Artikel wurde ursprünglich von Terry Slattery verfasst und von der ComputerWeekly-Redaktion aktualisiert, um Branchenveränderungen widerzuspiegeln und das Leseerlebnis zu verbessern.