Ein Änderungskalender und Wartungsfenster für ein kleines Betriebsteam

Ziel

"Was hat sich geändert?" während eines Vorfalls mit einem Blick beantworten können, riskante Änderungen aus den Stunden heraushalten, in denen niemand reagieren kann, und Nutzer vor geplanten Störungen vorwarnen.

Voraussetzungen

Ein gemeinsamer Kalender oder eine einfache Tabelle, die alle, die deployen, lesen und beschreiben können; Einigkeit darüber, was als Änderung zählt (Deploys, Schemamigrationen, DNS- und Zertifikatsänderungen, Wartung durch Anbieter, Infrastruktur-Upgrades, Feature-Flag-Umschaltungen mit Nutzerauswirkung); ein Vorfallskanal, in dem der Kalender verlinkt ist.

Schritte

1. Das Eintragsformat festlegen: was, verantwortliche Person, Beginn und erwartetes Ende, betroffene Systeme, erwartete Nutzerauswirkung (keine, eingeschränkt, Ausfall), Rollback-Plan, Prüfschritt. Je eine Zeile. Eine Änderung ohne Rollback-Angabe wird nicht eingeplant.
2. Feste Zeitfenster festlegen: ein Routinefenster für risikoarme Änderungen während der Arbeitszeit, wenn die verantwortliche Person und eine zweite Person erreichbar sind, sowie ein Wartungsfenster für störende Arbeiten, das vorab auf der Statusseite angekündigt wird. Zeitfenster in einer benannten Zeitzone angeben.
3. Sperrregeln festlegen: keine störende Änderung am Tag vor einem Feiertag, während eines Launches, während eines laufenden Vorfalls oder wenn die für die Änderung verantwortliche Person zugleich Rufbereitschaft ohne Vertretung hat. Sperrzeiten sind ebenfalls Kalendereinträge und damit sichtbar.
4. Ereignisse der Anbieter ergänzen. Hosting- und Cloud-Anbieter kündigen Wartungsarbeiten an; diese in denselben Kalender übernehmen, damit sie während eines Vorfalls nicht mit internen Änderungen verwechselt werden.
5. Vor Beginn postet die verantwortliche Person "starting <Eintrag>" im Betriebskanal und danach "done, verified" oder "rolled back". Automatisierte Deploys posten dieselben Meldungen aus der Pipeline.
6. Während eines Vorfalls lautet die erste Frage: was hat in den letzten Stunden begonnen oder geendet? Einträge ohne Endzeit sind die ersten Verdächtigen.
7. Monatlich überprüfen: Änderungen ausserhalb der Zeitfenster, Änderungen ohne Rollback-Angabe, Vorfälle, deren Ursache eine geplante Änderung war. Die Regeln anpassen statt zusätzliche Freigabeschritte einzuführen.

Erwartetes Ergebnis

Einsatzkräfte bringen Symptome innerhalb von Minuten mit Änderungen in Verbindung; störende Arbeiten landen nicht mehr versehentlich spät an einem Freitag; Nutzer sehen geplante Wartung, bevor sie beginnt.

Grenzen und Prüfbasis

Die Zahl von 70 % ist der im SRE-Buch berichtete Befund von Google SRE, keine universelle Konstante. Ein Kalender, der für jedes Deploy eine Freigabe verlangt, verlangsamt die Auslieferung und wird umgangen; der Aufwand pro Eintrag sollte gering bleiben, Freigaben bleiben der Kategorie Wartungsfenster vorbehalten. Es wird weder eine Adoptionsrate noch eine Reduktion von Ausfällen behauptet.