Ein Postmortem (auch Incident Review oder Störfallanalyse) ist die strukturierte Aufarbeitung eines Störfalls nach dessen Behebung. Ziel ist nicht, Schuldige zu finden, sondern aus dem Vorfall zu lernen: Was ist passiert, warum, und wie lässt sich ein Wiederholen verhindern? Der Begriff stammt aus der Medizin (lateinisch „nach dem Tod“) und bezeichnet dort die Leichenschau; in der IT steht er für die retrospektive Untersuchung eines Incidents.
Die Blameless-Kultur
Das Google-SRE-Buch propagiert das blameless postmortem (schuldfreie Störfallanalyse): Statt Menschen für Fehler zu belangen, analysiert das Team die Kette aus Umständen, Automatisierungslücken und Prozessschwächen, die den Vorfall ermöglicht haben. Erst diese Schuldfreiheit motiviert Ingenieure, ehrlich über Fehler zu berichten — und nur so entstehen belastbare Root-Cause-Analysis-Ergebnisse. Fehler werden als System-Eigenschaft betrachtet, nicht als individuelle Schwäche.
Aufbau eines Postmortems
Ein typisches Postmortem dokumentiert: die Chronologie des Vorfalls (Timeline mit Zeitstempeln), die Auswirkungen (betroffene Nutzer, Dauer, SLA-Verletzungen), die Root-Cause-Analysis (häufig mit der 5-Whys-Technik), die Sofortmaßnahmen sowie konkrete Folgeaufgaben mit Verantwortlichen und Terminen. Die Wirksamkeit zeigt sich in der Umsetzung: Ein Postmortem ohne nachverfolgte Aktions-Items ist nur ein Protokoll.
Abgrenzung und Einordnung
Während das Runbook beschreibt, wie ein bekannter Störfall behoben wird, klärt das Postmortem warum er entstanden ist. Es ist das letzte Glied im Incident-Management-Zyklus: Alerting meldet, Incident-Management behebt, das Postmortem verhindert künftige Wiederholungen. Moderne Teams ergänzen es durch proaktive Übungen wie Chaos Engineering und Game Day.
Verwandte Grundlagen: Incident-Management, Error Budget, Observability.