Einen Störungsplan für ein kleines Softwareteam ausfüllen

Ein Störungsplan muss Ihrem Team helfen, unterbrochene Arbeit geordnet zu bearbeiten. Wählen Sie dafür einen wichtigen Ablauf Ihrer Software und beschreiben Sie, woran sein Ausfall erkannt wird, wer entscheidet und welcher Nachweis für die Wiederaufnahme nötig ist.

Den betroffenen Ablauf benennen

Im erfundenen Entwurf betrifft die Störung I-72 ein Kundenportal. Die Startseite antwortet, aber neue Anfragen lassen sich nicht vollständig mit einer Anlage speichern. Die Anfrage A-72 und die Datei F-72 dienen nur als Testbeispiel. Es ist keine hier beobachtete Betriebsstörung.

Für diesen Fall wird nicht die bloße Erreichbarkeit der Startseite zum Abschlusskriterium. Der Plan nennt den vollständigen Anfrageablauf einschließlich Dateiablage, Rollenprüfung und nachgelagerter Arbeit. Außerdem wird festgehalten, welche Änderungen während der Bearbeitung erlaubt sind.

Eine Reaktionskarte mit Rollen ausfüllen

Google SRE beschreibt klare Rollen, einen aktuellen Arbeitsstand und bestätigte Übergaben. Kleine Teams können mehrere Rollen bei einer Person bündeln. Es muss dennoch erkennbar bleiben, wer koordiniert, wer das System verändert und wer Informationen weitergibt.

Die Tabelle beschreibt geplante Schritte, keine ausgeführte Wiederherstellung. Legen Sie eine Vertretung und einen erreichbaren Eskalationskontakt fest. Die Arbeitsunterlage muss auch bei Ausfall des Portals verfügbar sein.

Kommunikation als eigene Aufgabe planen

Benennen Sie, wer betroffene Personen und beteiligte Dienste informiert. Eine Statusmeldung nennt die bekannte Auswirkung, den aktuellen Bearbeitungsstand und den nächsten vereinbarten Meldepunkt. Eine geschätzte Ursache ist als Vermutung erkennbar; eine unbelegte Wiederherstellungszeit wird nicht als Zusage weitergegeben.

Bei einem Personalwechsel während der Störung wird der aktuelle Stand übergeben und die Übernahme bestätigt. Zur Übergabe gehören auch erfolglose Maßnahmen und noch offene Prüfungen. Eine bloß versandte Nachricht stellt nicht sicher, dass die neue Koordination übernommen wurde.

Wiederaufnahme und Nacharbeit unterscheiden

Vor der Wiederaufnahme prüft das Team den betroffenen Ablauf in einer geeigneten Umgebung mit den vereinbarten Testfällen. Ob eine Rückkehr zu einem früheren Zustand möglich ist, hängt auch vom inzwischen veränderten Datenstand ab; ein Neustart allein ist kein Wiederherstellungsnachweis.

Halten Sie fest, wer die Wiederaufnahme freigibt und welche offenen Arbeiten weiter beobachtet werden. Die anschließende Ursachenanalyse darf den Plan verbessern, muss aber nicht mit der ersten Stabilisierung gleichgesetzt werden. Üben Sie die Karte anhand eines freigegebenen Szenarios und korrigieren Sie fehlende Kontakte, Zugänge oder Prüfschritte.

Quellen

• Google SRE: Managing Incidents