Post-Mortems ohne Schuld: Lernen, Maßnahmen, Follow-up.
Post-Mortems ohne Schuld: Wie man aus Incidents wirklich lernt
Ein Post-Mortem, das zur Schuldzuweisung wird, produziert keine Learnings. Es produziert Angst.
Was ein gutes Post-Mortem leisten soll
Nicht: Wer ist schuld? Sondern: Was hat zu dem Incident geführt? Was hat das System anfällig gemacht? Was müssen wir ändern, damit das nicht wieder passiert?
Die Unterscheidung klingt semantisch. Sie ist kulturell fundamental.
Blameless Culture
Google's SRE-Buch hat es populär gemacht: Blameless Post-Mortems. Die Grundannahme ist, dass Menschen gut handeln wollen und Incidents systemische Ursachen haben – nicht individuelle Fehler.
Das bedeutet nicht: Fehler ignorieren. Sondern: Systemebene und Prozessebene analysieren, nicht Personenebene.
Die Post-Mortem-Struktur
Timeline: Was ist wann passiert? Objektiv, ohne Bewertung.
Root Cause: Was war die Grundursache? Nicht das Symptom. "Der Server war überlastet" ist ein Symptom. "Der Deployment-Prozess hat keine Load-Tests vor Produktions-Rollout" ist eine Ursache.
Contributing Factors: Was hat den Incident verschlimmert oder verlängert? Fehlende Alerts, unklar definierte On-Call-Verantwortung, schlechte Runbooks.
Action Items: Konkrete Maßnahmen mit Owner und Deadline. Nicht "wir sollten mehr testen". Sondern "Person X richtet Load-Tests bis Datum Y in der CI-Pipeline ein."
Follow-up: Wurden die Action Items umgesetzt? Das ist der häufigste Schwachpunkt.
Checkliste Post-Mortem
Timeline lückenlos und objektiv dokumentiert
Root Cause analysiert (5-Whys oder Fishbone-Analyse)
Contributing Factors identifiziert
Action Items mit Owner und Deadline
Post-Mortem im Team geteilt
Follow-up-Termin für Action Items eingetragen
Incident-Review-Prozess einführen?
markom.digital hilft beim Aufbau von Incident-Management-Prozessen – mit Blameless-Kultur und echten Learnings.
