Wenn ein IT-System ausfällt, beginnt danach unweigerlich die Frage: Wer hat was falsch gemacht? Diese Frage klingt verständlich, führt aber in den meisten Fällen zu schlechten Ergebnissen. Teams, die sich auf Schuld konzentrieren, lernen wenig aus Incidents – und riskieren, denselben Fehler erneut zu machen. Das Blameless Postmortem ist eine Methode, die genau das vermeiden soll: Es analysiert Störungen ohne Schuldzuweisungen, um systemische Schwachstellen zu verstehen und dauerhaft zu beheben.
Was ein Blameless Postmortem ist – und was nicht
Der Begriff wurde durch Google und die SRE-Bewegung popularisiert, hat aber inzwischen in fast allen professionellen IT-Organisationen Einzug gehalten. Ein Blameless Postmortem ist ein strukturierter, schriftlicher Bericht, der nach einem bedeutsamen Incident erstellt wird. Ziel ist es, den genauen Ablauf zu rekonstruieren, Ursachen zu verstehen und konkrete MaĂźnahmen abzuleiten.
Das „Blameless" bedeutet dabei: Keine Person wird als Schuldige benannt. Warum? Weil Menschen in komplexen Systemen Fehler machen – nicht aus Böswilligkeit, sondern weil das System es ihnen ermöglicht oder sogar unvermeidlich macht. Wer nach dem Schuldigen sucht, behebt den Symptomträger, aber nicht die Ursache. Wer nach dem Systemproblem sucht, verbessert dauerhaft die Infrastruktur, Prozesse und Werkzeuge.
„We want to be honest about the fact that individual engineers are not the problem. The system is the problem." – Google SRE Handbook
Wann ein Postmortem sinnvoll ist
Nicht jeder Alarm erfordert ein vollständiges Postmortem. Die meisten Teams legen interne Schwellenwerte fest. Typische Auslöser:
- Kundenseitig sichtbarer Ausfall oder Einschränkung, der länger als eine definierte Dauer anhält
- Ăśberschreitung eines definierten SLO- oder Error-Budget-Grenzwerts
- Datenverlust oder sicherheitsrelevanter Vorfall
- Manueller Eingriff war nötig, um ein automatisiertes System zu retten
- Mehrfaches Auftreten desselben Problems innerhalb kurzer Zeit
Entscheidend ist: Der Schwellenwert sollte im Team explizit vereinbart sein, nicht ad hoc nach Stimmungslage entschieden werden. Wenn unklar ist, ob ein Postmortem nötig ist, ist es meist besser, eines zu schreiben – der Aufwand zahlt sich durch Lerneffekte langfristig aus.
Die Struktur eines guten Postmortems
Ein Postmortem ist kein freier Text, sondern folgt einer klaren Struktur. Die meisten Teams verwenden Vorlagen. Die wichtigsten Abschnitte:
1. Zusammenfassung
Ein kurzer Überblick: Was ist passiert, wann, wie lange, welche Auswirkungen hatte der Incident? Diese Zusammenfassung sollte in 3 bis 5 Sätzen lesbar sein – auch für Personen, die nicht im technischen Detail stecken.
2. Zeitlinie
Eine chronologische Rekonstruktion des Incidents: Wann wurde das Problem erkannt? Welche Maßnahmen wurden ergriffen? Wann war der Incident behoben? Die Zeitlinie hilft, Reaktionszeiten zu analysieren und Lücken in der Erkennung oder Kommunikation zu finden. Präzise Timestamps aus Monitoring-Daten und Alert-Logs sind hier Gold wert.
3. Ursachenanalyse
Hier wird die eigentliche Arbeit geleistet. Ziel ist nicht, einen einzigen Fehler zu benennen, sondern mehrere beitragende Faktoren zu identifizieren. Die „5-Whys"-Methode ist ein bewährtes Werkzeug: Warum ist X passiert? Weil Y. Warum Y? Weil Z. Und so weiter, bis die systemische Ursache sichtbar wird.
4. Auswirkungen
Wie viele Nutzer waren betroffen? Wie lange? Welche SLOs wurden verletzt? Dieser Abschnitt liefert die Grundlage für Prioritätsentscheidungen bei den Maßnahmen und zeigt, ob das Error Budget des Teams noch ausreicht.
5. MaĂźnahmen
Der wichtigste Abschnitt für die Zukunft. Jede Maßnahme braucht einen konkreten Owner und eine realistische Frist. Vage Formulierungen wie „Monitoring verbessern" sind wertlos. Besser: „Alert für Fehlerrate über 5 % auf /api/checkout hinzufügen bis 30.06." Maßnahmen sollten priorisiert werden: Was verhindert eine Wiederholung? Was verbessert die Erkennungszeit? Was stärkt die Reaktionsfähigkeit?
Häufige Fehler beim Postmortem
Selbst Teams, die Postmortems regelmäßig schreiben, machen systematische Fehler:
- Keine Zeitlinie: Ohne genaue Timeline lässt sich die Reaktionszeit nicht bewerten und nicht verbessern.
- Einzelne Ursache statt Systemsicht: „Der Engineer hat den falschen Config-Wert gesetzt" erklärt nicht, warum kein Review-Prozess das verhindern konnte.
- MaĂźnahmen ohne Owner: Action Items ohne klar benannte Verantwortliche verschwinden im Team-Backlog und werden nie umgesetzt.
- Postmortem nach Wochen: Je länger das Schreiben aufgeschoben wird, desto mehr Details gehen verloren. Ideal ist ein Zeitraum von 24 bis 72 Stunden nach dem Incident.
- Kein Follow-up: Ob Maßnahmen tatsächlich umgesetzt wurden, wird nie geprüft. Ohne Review-Prozess verliert das Postmortem seinen Wert.
Kultur schaffen: Blameless bedeutet nicht kritikfrei
Ein häufiges Missverständnis: Blameless bedeutet nicht, dass alles gut war. Es bedeutet, dass die Analyse systemisch und nicht personalisiert erfolgt. Ein Team kann gemeinsam feststellen, dass ein Deployment-Prozess unzureichend war – ohne dabei eine Person anzuprangern. Das schafft psychologische Sicherheit, die notwendig ist, damit Ingenieure offen über Fehler sprechen.
Diese Kultur entsteht nicht durch eine einmalige Ankündigung, sondern durch konsequentes Vorleben. Wenn Management auf Postmortems reagiert, indem doch nach Schuldigen gesucht wird, scheitert die Methode sofort. Führungskräfte müssen aktiv dazu beitragen, dass Postmortems als Lernwerkzeug und nicht als Rechtfertigungsdokument wahrgenommen werden.
Postmortem-Repository: Der kollektive Wissensspeicher
Ein gut gepflegtes Postmortem-Repository – also eine durchsuchbare Sammlung aller vergangenen Berichte – ist langfristig einer der wertvollsten Wissensschätze eines IT-Teams. Wer darin nach Mustern sucht, findet oft, dass bestimmte Systemkomponenten, Deployment-Zeitfenster oder Konfigurationsprozesse überproportional oft auftauchen. Dieses Muster zeigt zuverlässig, wo Investitionen am meisten bringen.
Manche Teams nutzen RAG-Systeme (Retrieval-Augmented Generation), um ihr Postmortem-Archiv für KI-gestützte Incident-Analyse zugänglich zu machen. So kann ein Sprachmodell bei einem neuen Incident automatisch ähnliche Fälle aus der Vergangenheit heranziehen – ein praktischer Beweis dafür, wie strukturiertes Lernen aus Störungen sich mit KI-Werkzeugen multiplizieren lässt.
Werkzeuge und Vorlagen
Die meisten Teams starten mit einer einfachen Vorlage in Google Docs, Notion oder Confluence. Dedizierte Tools wie FireHydrant, Rootly oder das gleichnamige Produkt Blameless bieten Vorlagen, automatisierte Zeitlinien aus Alert-Daten und Integrationsmöglichkeiten mit PagerDuty, Slack oder Jira. Für kleinere Teams reicht eine gut gepflegte Vorlage in einem gemeinsamen Wiki vollkommen aus – entscheidend ist Konsistenz, nicht das Werkzeug.
Monitoring als Grundlage
Die Qualität einer Zeitlinie hängt direkt von der Qualität des Monitorings ab. Ohne gute Alerts, strukturierte Logs und eine verlässliche Übersicht über Systemzustände lässt sich ein Incident post-hoc kaum rekonstruieren. Teams, die Monitoring als Grundlage für Postmortems nutzen, investieren zwangsläufig in bessere Metriken und Alerting – und reduzieren damit gleichzeitig die Erkennungszeit beim nächsten Incident.
Fazit
Blameless Postmortems sind kein bürokratisches Ritual, sondern ein strategisches Werkzeug. Sie verwandeln Störungen in Verbesserungsprogramme – wenn sie konsequent und ehrlich durchgeführt werden. Der Aufwand für ein gutes Postmortem zahlt sich aus: durch weniger Wiederholungen, schnellere Reaktionszeiten und ein Team, das sich traut, Probleme offen zu benennen. Die wichtigste Voraussetzung ist nicht das beste Werkzeug, sondern eine Kultur, in der Lernen wichtiger ist als Schuld zuweisen.
Quellen: Google SRE Handbook (sre.google/sre-book), Atlassian Incident Management Guide (atlassian.com), PagerDuty Postmortem Guide, FireHydrant Blog, allgemeine Fachliteratur zu Incident Response und SRE.
