EMZETT.Incident-Management und Postmortems
Kurz: Der geordnete Umgang mit Störungen: schnell erkennen, beheben, kommunizieren und danach ohne Schuldzuweisung daraus lernen.
Genauer: Ein Incident ist ein Ereignis, das einen Dienst unerwartet beeinträchtigt, etwa ein Ausfall oder stark erhöhte Fehlerraten. Incident-Management regelt Rollen, Abläufe und Kommunikation, damit unter Druck nicht improvisiert werden muss. Das Postmortem (Nachbesprechung) hält fest, was passiert ist und wie man es künftig verhindert.
Im Detail
Ablauf während einer Störung
- Erkennen: Alarm durch Monitoring oder Meldung von Nutzern.
- Einstufen: Wie schwer ist es (Schweregrad, betroffene Nutzer)?
- Koordinieren: Eine Person leitet (Incident Commander), andere untersuchen, eine kommuniziert.
- Mildern: Zuerst die Auswirkung stoppen (zurückrollen, abschalten, umschalten), erst danach die Ursache suchen.
- Informieren: Statusseite und Kundenmitteilungen mit ehrlichem Stand.
- Abschließen: Normalbetrieb bestätigen.
Das Postmortem
Es enthält eine Zusammenfassung, eine Zeitleiste mit Uhrzeiten, die Auswirkung (Dauer, Anzahl Betroffener), die Ursachen (meist mehrere, nicht nur „ein Fehler“), was gut und schlecht lief, und konkrete Maßnahmen mit Verantwortlichen und Terminen. Hilfreich ist die Frage „Warum?“ mehrfach hintereinander („Fünf Warum“).
Ohne Schuldzuweisung
Ein „blameless“ Postmortem fragt nicht, wer schuld war, sondern warum das System es einer Person erlaubt hat, einen Fehler zu machen. Wer Angst vor Vorwürfen hat, verschweigt Dinge, und die Organisation lernt weniger. Menschliche Fehler sind meist ein Zeichen für fehlende Sicherungen wie Prüfungen, Tests oder Rückfallmöglichkeiten.
Kennzahlen
Gängig sind MTTD (Zeit bis zum Erkennen), MTTR (Zeit bis zur Wiederherstellung) und die Zahl der Incidents. Sie sollten Hinweise geben, nicht als Wettbewerb dienen. Auch kleine Projekte profitieren von einer kurzen Notiz nach jeder Störung.
Siehe auch: SLI, SLO und Error Budget, SLA, Support-Level und Ticketsystem, Chaos Engineering