Postmortem-Checkliste (Störungsanalyse)
Postmortem-Vorlage als Checkliste für eine schuldfreie Störungsanalyse: Zeitablauf, Auswirkungen, Ursachen, Maßnahmen und Nachverfolgung nach jedem Incident.
- Typischer Rhythmus pro Incident
- Die Checkliste 5 Abschnitte, 18 Punkte
- Variablen
{{incident_title}} - Aus der CI starten
Diese Checkliste ist für jede Störung gedacht, die Kunden betroffen hat, einen hohen Schweregrad ausgelöst hat oder knapp davor war. Beinahe-Ausfälle sind oft die günstigsten Lektionen. Die Checkliste ersetzt nicht das Postmortem-Dokument selbst. Sie stellt sicher, dass es geschrieben und geprüft wird und vor allem, dass die vereinbarten Maßnahmen tatsächlich umgesetzt werden.
Wer verantwortlich ist
Eine Postmortem-Verantwortliche oder ein Postmortem-Verantwortlicher, oft die Incident-Leitung, begleitet den Durchlauf vom ersten Entwurf bis zur letzten erledigten Maßnahme. Diese Person sammelt die Fakten und moderiert das Review-Meeting. Sie entscheidet nicht allein über alle Korrekturen. Jede Maßnahme bekommt eine eigene verantwortliche Person.
Typische Fehler
- Schuldzuweisung durch die Hintertür. „Menschliches Versagen“ ist ein Ausgangspunkt, kein Ergebnis. Fragen, was den Fehler leicht gemacht und schwer erkennbar gemacht hat, und genau das beheben.
- Nur eine Ursache. Die meisten Störungen haben mehrere beitragende Faktoren: eine Änderung, ein fehlender Alarm, ein unklares Runbook. Wer nur einen nennt, verdeckt die anderen.
- Zu lange warten. Chatverläufe scrollen weg, Erinnerungen verblassen. Den Zeitablauf innerhalb weniger Arbeitstage entwerfen.
- Maßnahmen ohne Verantwortliche. „Monitoring verbessern“ wird nie erledigt. Jede Maßnahme braucht eine konkrete Änderung, eine verantwortliche Person und eine Frist.
Ohne Schuldzuweisung arbeiten
Beschreiben, was die Beteiligten gesehen haben und warum ihr Handeln in dem Moment sinnvoll war. Wer keine Bewertung fürchten muss, erzählt mehr, und das führt zu besseren Korrekturen.
Starten Sie den Durchlauf, sobald die Störung behoben ist, damit es nicht vom Gedächtnis einzelner abhängt. Der Durchlauf bleibt offen, bis die letzte Maßnahme abgehakt ist.
Die Checkliste: Postmortem {{incident_title}}
Fakten sammeln
-
Postmortem-Verantwortliche Person benannt und Review-Meeting angesetzt
-
Zeitablauf aus Chat, Alarmen, Deploy-Logs und Statusseite mit Zeitstempeln erstellt
Erkennung, Eskalation, jeden Behebungsversuch und die Lösung aufnehmen.
-
Auswirkungen auf Kunden beziffert: wer betroffen war, wie und wie lange
Echte Zahlen aus Logs oder Support-Tickets verwenden, keine Schätzungen.
-
Erkennung geprüft: wie die Störung bemerkt wurde und wie lange das gedauert hat
-
Beteiligte vor dem Meeting nach ihrer Sicht gefragt
Analysieren
-
Beitragende Faktoren gelistet: technisch, prozessual und organisatorisch
-
Jeder Faktor mit „warum war das in dem Moment plausibel“ erklärt, nicht mit Schuldfragen
-
Festgehalten, was gut lief, damit es beibehalten wird
-
Entwurf von mindestens einer beteiligten Person auf Richtigkeit geprüft
Review-Meeting
-
Meeting mit den Beteiligten und den Verantwortlichen der betroffenen Systeme durchgeführt
-
Maßnahmen vereinbart, jeweils mit konkreter Änderung, verantwortlicher Person und Frist
Korrekturen bevorzugen, die das Problem automatisch verhindern oder erkennen, statt „besser aufpassen“.
-
Maßnahmen von der Teamleitung gegenüber anderen Aufgaben priorisiert
Veröffentlichen
-
Postmortem dort veröffentlicht, wo das ganze Team es findet
-
Zusammenfassung für Kunden verschickt oder veröffentlicht optional
Sinnvoll nach größeren Ausfällen. Sachlich bleiben, ohne interne Namen.
-
Runbooks, Alarme und Bereitschaftsdokumentation mit den Erkenntnissen aktualisiert
Nachverfolgen
-
Maßnahmen als Tickets angelegt und im Postmortem verlinkt
-
Offene Maßnahmen im nächsten Team-Meeting besprochen
-
Alle Maßnahmen erledigt oder mit Begründung ausdrücklich verworfen
Checkliste als Markdown
Diese Checkliste aus der Pipeline starten
Wenn ein Incident im Tool als gelöst markiert wird, POST /api/v1/runs mit der Vorlage "Postmortem {{incident_title}}" und dem Incident-Titel als incident_title aufrufen.
curl -X POST https://runbook.metastic.ch/api/v1/runs \
-H "Authorization: Bearer $RUNBOOK_TOKEN" \
-H "Content-Type: application/json" \
-d '{"template": "Postmortem {{incident_title}}", "variables": {"incident_title": "…"}}'Häufige Fragen
Was gehört in eine Postmortem-Vorlage?
Ein gutes Postmortem enthält eine Zusammenfassung, die Auswirkungen, einen Zeitablauf, die beitragenden Faktoren, was gut lief, und eine Liste von Maßnahmen mit Verantwortlichen und Fristen. Das Dokument so kurz halten, dass es auch gelesen wird. Die Maßnahmen sind der wichtigste Teil.
Was bedeutet Blameless Postmortem?
Ein Blameless Postmortem, also eine Störungsanalyse ohne Schuldzuweisung, untersucht, wie System und Prozess die Störung ermöglicht haben, statt zu fragen, wer einen Fehler gemacht hat. Es geht davon aus, dass alle mit den verfügbaren Informationen vernünftig gehandelt haben. So sprechen Beteiligte offener darüber, was wirklich passiert ist.
Wann sollte ein Postmortem geschrieben werden?
Innerhalb weniger Arbeitstage nach der Störung beginnen, solange Logs und Erinnerungen frisch sind. Das Review-Meeting innerhalb von ein bis zwei Wochen abhalten. Vorab festlegen, welche Störungen ein Postmortem brauchen, zum Beispiel jeder Ausfall mit Kundenwirkung und jeder Incident mit hohem Schweregrad.
Aktualisiert