Nach einem Incident mit Schaden oder Beinahe-Schaden schafft die Methode ein nüchternes Lernfeld ohne Schuldzuweisung. Sie richtet den Blick auf Verlauf, Bedingungen und wirksame Gegenmaßnahmen.
Blameless Postmortem
Rekonstruiert ein Störungsereignis ohne Schuldzuweisung und übersetzt Ursachen in konkrete Verbesserungsaktionen.
Welche Systembedingungen und Entscheidungspunkte haben den Incident möglich gemacht, und welche konkreten Massnahmen verhindern die Wiederholung?
Der Vorfall wird so rekonstruiert, dass Fakten und Entscheidungen nachvollziehbar bleiben, ohne Menschen zum Erklärziel zu machen. Dadurch treten systemische Beiträge und Signale aus dem Alltag klarer hervor. Die nachfolgenden Verbesserungen zielen auf Robustheit statt auf persönliche Rechtfertigung.
Visuelle Orientierung
Methodenskizze für ein schnelles Grundgefühl.
Ablauf
- 1Incident dokumentieren
- 2Impact und Timeline beschreiben
- 3Contributing Causes identifizieren
- 4Corrective Actions festlegen
- 5Learnings teilen
Das Runsheet führt mit 5 Phasen, Timeboxen, 6 Stolperfallen und klaren Abbruchkriterien durch die Umsetzung.
Runsheet öffnenIdeal für
- Incidents
- Outages
- Reliability Culture
Nicht gut für
- Performance Evaluation
- Punitive Investigations
Vertiefung
Ein Blameless Postmortem schafft Lernfähigkeit nach Störungen, weil es Entscheidungen im Kontext rekonstruiert statt Schuldige zu suchen. Timeline, Impact, beitragende Faktoren und Maßnahmen brauchen klare Trennung. Der Nutzen entsteht, wenn das Team bessere Schutzmechanismen, Signale oder Recovery-Pfade ableitet und die Geschichte des Incidents nachvollziehbar bleibt.
Sichere Timeline, Logs, Screenshots und getroffene Entscheidungen, solange der Vorfall noch frisch im Gedächtnis liegt. Die Stimmung bleibt konstruktiv, wenn Formulierungen Bedingungen, Signale und Trade-offs beschreiben statt Personen zu bewerten. Schließe mit Systemänderungen, einem Nachverfolgungsweg und einem Termin, an dem die Wirksamkeit der Maßnahmen überprüft wird.
Blameless PostmortemVorlage für Lernen, beitragende Faktoren und Maßnahmen nach einem Incident.markdown
postmortem-markdown.md
Vorlage für Lernen, beitragende Faktoren und Maßnahmen nach einem Incident.
Blameless Postmortem
Zusammenfassung
Was ist passiert, welche Wirkung hatte es?
Impact
- Kundenauswirkung:
- Dauer:
- Betroffene Systeme:
Timeline
Link oder Auszug der Timeline.
Beitragende Faktoren
- ...
Was lief gut?
- ...
Was verbessern wir?
| Maßnahme | Owner | Datum | Erwartete Wirkung |
|---|
Follow-up
Review-Termin und Status.
Wann stattdessen?
Kurze Entscheidungshilfe für vorhandene Alternativen.
Statt Blameless Postmortem, wenn ihr nach einem Ereignis rasch lernen und konkrete Verbesserungen festhalten wollt.
Ähnliche Methoden
Alle MethodenOrdnet Ereignisse, Entscheidungen und Verzögerungen chronologisch und macht Ursachen sowie Lernpunkte sichtbar.
Verlegt Incident Response in einen gemeinsamen Thread, verbindet Alerts mit Commands und macht Entscheidungen nachvollziehbar.
Simuliert realistische Störungsszenarien, deckt Lücken in Response und Runbooks auf und verbessert Vorbereitung.
Koordiniert Rollen, Kommunikation und Maßnahmen im Störungsfall, sodass Lagebild und Entscheidungen zusammenlaufen.
Untersucht einen Vorfall mit Blick auf Entscheidungen, Annahmen und Systemfaktoren und hält Lernergebnisse fest.
Macht Muster aus einem Sprint sichtbar und leitet daraus konkrete Verbesserungen für den nächsten Arbeitszyklus ab.