Wartungsfenster und Change-Freeze: Wann darf an der Produktion gearbeitet werden?

Es ist Donnerstagmittag und der Change-Manager überprüft eine Änderung an einem Datenbankcluster. Das vorgeschlagene Datum sieht gut aus. Was niemand bemerkt, ist, dass für dieselbe Nacht ein Update des Speichers unter demselben Cluster geplant ist, dass die betroffene Anwendung nur ein Wartungsfenster am Sonntagmorgen hat und dass das Monatsabschlussverfahren läuft, eine Periode, in der die Produktion gar nicht angefasst werden sollte. All dies ist irgendwo schriftlich festgehalten. Nur nicht an einem Ort.

Jeder, der Erfahrungen in der Betriebsführung hat, weiß, wie das endet: ein früher Anruf, ein besorgter Service Owner und ein Team, das erklärt, warum zwei Änderungen kollidiert sind, anstatt die geplanten Arbeiten durchzuführen. Dies liegt selten an Sorglosigkeit. Es liegt daran, dass die Regeln für das Anfassen der Produktion nicht sichtbar genug für die Personen sind, die Änderungen planen.

Warum Tabellenkalkulationen und Goodwill nicht ausreichen

Wir sehen oft, dass Wartungsfenster in Verträgen oder Service-Dokumentationen festgehalten sind, Einfrierungen per E-Mail angekündigt werden und Kollisionen von einem erfahrenen Kollegen aufgespürt werden, der "weiß, was wo läuft". Das funktioniert, solange das Änderungsvolumen gering ist und dieser Kollege nicht im Urlaub ist.

Die Schwachstellen sind vorhersehbar:

• das Wartungsfenster gehört zum Service, aber die Änderung ist auf einem Server geplant, sodass jemand die Verbindung manuell nachvollziehen muss,
• eine Einfrierung wird angekündigt, aber nie durchgesetzt,
• zwei Änderungen auf gemeinsamer Infrastruktur werden erst entdeckt, wenn jemand den Kalender überprüft, wenn überhaupt,
• große Änderungen an vielen Elementen werden auf einmal ausgeführt, weil eine schrittweise Einführung schwer zu planen ist.

Wie man es angeht

Die Kernidee ist einfach: Regeln sollten Daten sein, kein Stammeswissen. Ein Wartungsfenster gehört zu einem Service und muss von jedem Element, von dem der Service abhängt, nachvollziehbar sein. Eine Einfrierung ist eine Periode, in der das System keine Änderungsdatum akzeptiert. Kollisionen sollten während der Planung bewertet werden, nicht durch bloßes Hinsehen.

Es ist ebenso wichtig zuzugeben, dass nicht jede Situation in strenge Regeln passt. Wenn ein neuer Prozess eingeführt wird oder in einer Organisation, die nie Wartungsfenster definiert hat, ist eine bewusste und nachvollziehbare Ausnahme besser als Regeln, die jeder umgeht.

Wie Eywo Stratum es handhabt

In Eywo Stratum ist eine Änderung mit CMDB-Elementen und über die Abhängigkeitskarte mit den Diensten verknüpft, die darauf laufen. Bevor eine Änderung zur Genehmigung eingereicht wird, berechnet das System ihre Auswirkungen: Welche Dienste und Anwendungen werden down oder beeinträchtigt sein?

Zeitplanregeln bauen auf dieser Berechnung auf:

• Wartungsfenster – eine Änderung kann nur innerhalb der Fenster der betroffenen Dienste geplant werden,
• Change-Freeze – eine Änderung kann während einer Einfrierung nicht geplant werden,
• Kollisionen – das System markiert andere Änderungen, die sich in Zeit und Umfang überschneiden,
• rollierende Ausführung – eine Änderung kann Element für Element durchgeführt werden, sodass ein redundanter Dienst nicht als Ganzes down gehen muss.

Jede Änderung erscheint im Änderungskalender, wo der Change-Manager und die Service Owner sehen können, was kommt und wann. Der Eigentümer des betroffenen Dienstes genehmigt die Ausfallzeit, und je nach Änderungsmodell tun dies auch der Change-Manager oder das CAB. Standardmäßig vorab genehmigte Änderungen bewegen sich schnell; normale und Notfalländerungen haben ihre eigenen Schritte und Vorlaufzeiten.

Für die Einführungsperiode bietet Eywo Stratum ein "Änderung ohne Wartungsfenster"-Modell an. Dies ermöglicht einer Organisation, Änderungen aufzuzeichnen und zu genehmigen, bevor jeder Dienst ein definiertes Fenster hat. Die Ausnahme bleibt sichtbar und nachvollziehbar, und sobald die Fenster existieren, wechseln die Teams zu den Standardmodellen.

Ruhe statt Improvisation

Wartungsfenster und Einfrierungen sind keine Bürokratie. Sie sind Vereinbarungen zwischen Betrieb und den Personen, die auf einen Dienst angewiesen sind. Wenn das System sie durchsetzt, kann sich der Change-Manager auf den Inhalt einer Änderung konzentrieren, anstatt Kalender zu durchsuchen, und die Ingenieure beginnen ihre Nachtschicht, wissend, dass niemand sonst an derselben Infrastruktur arbeitet. Jeder kann mit einem klareren Kopf nach Hause gehen.

Wartungsfenster, Einfrierungen, Kollisionüberprüfungen und der Änderungskalender sind in der Standard-Edition enthalten.