Ein Postmortem ist eine strukturierte, schriftliche Auswertung nach einem Incident. Es dokumentiert die Auswirkung auf Kunden, eine Zeitlinie von Erkennung und Reaktion, die technischen und organisatorischen Faktoren, die beigetragen haben, sowie konkrete Maßnahmen mit Verantwortlichen. Blameless Postmortems fragen, wie das System den Fehler zuließ, nicht, wer ihn verursacht hat.
Was ist ein Postmortem?
Ein Postmortem, auch Post-Incident-Review genannt, ist das Dokument und Meeting, das einen Incident abschließt. Sobald der Service wiederhergestellt ist, rekonstruiert das Team, was passiert ist, warum es passiert ist, wie es erkannt und behoben wurde und was sich ändert, damit dieselbe Fehlerklasse unwahrscheinlicher oder weniger schädlich wird. Die Praxis ist zentral für Site Reliability Engineering und greift eng ins Incident Management: Die Incident-Reaktion stellt den Service wieder her, das Postmortem verbessert das System.
Die meisten Teams verlangen ein Postmortem, sobald ein Incident eine definierte Schwelle überschreitet, etwa bei jedem für Nutzer sichtbaren Ausfall, einer Verletzung eines SLO oder einem großen Verbrauch des Error Budgets, bei Datenverlust oder bei manuellen Eingriffen durch die Rufbereitschaft.
Warum Postmortems schuldfrei sein müssen
Komplexe Systeme scheitern an Kombinationen latenter Bedingungen: ein fehlender Alert, ein missverständliches Dashboard, ein ungünstiger Konfigurations-Default, Zeitdruck. Endet ein Postmortem mit „Engineer X hat den falschen Befehl ausgeführt“, lernt die Organisation nichts darüber, warum der Befehl möglich war, warum er sicher wirkte und warum nichts ihn aufgehalten hat. Ein Blameless Postmortem geht davon aus, dass Menschen mit den verfügbaren Informationen vernünftig gehandelt haben, und fragt, wie Werkzeuge, Prozesse und Design ihre Entscheidungen geprägt haben. Es geht nicht darum, Verantwortung zu vermeiden, sondern um ehrliche und vollständige Schilderungen. Die gibt nur, wer keine Sanktionen befürchten muss.
Eine praxisnahe Postmortem-Vorlage
- Zusammenfassung: zwei oder drei Sätze dazu, was ausgefallen ist, wie lange und für wen.
- Auswirkung: betroffene Nutzer, Requests, Regionen und umsatzrelevante Abläufe; Verbrauch von SLO und Error Budget.
- Zeitlinie: Ereignisse mit Zeitstempel vom ersten Auslöser über Erkennung, Eskalation und Eindämmung bis zur vollständigen Wiederherstellung, in einer Zeitzone (meist UTC).
- Erkennung: wie das Problem bemerkt wurde, ob durch Alert, Kunden oder Zufall, und wie lange das gedauert hat.
- Beitragende Faktoren: technische Auslöser und die Bedingungen, unter denen sie Schaden anrichten konnten. Erzwingen Sie keine einzelne „Root Cause“.
- Was gut lief, was schlecht lief: einschließlich Werkzeugen, Runbooks und Kommunikation.
- Maßnahmen: konkret, priorisiert, jeweils mit verantwortlicher Person und Termin, verfolgt im regulären Backlog.
Beispiel: Auszug aus einer Zeitlinie
Eine Zeitlinie zur Veranschaulichung für ein fehlgeschlagenes Release:
| Zeit (UTC) | Ereignis |
|---|---|
| 14:02 | Deployment von checkout v2.41 startet; eine Konfigurationsänderung senkt den Datenbank-Connection-Pool von 50 auf 5. |
| 14:09 | p99-Latenz von POST /orders steigt von 300 ms auf 4 s, die Fehlerrate erreicht 6 Prozent. |
| 14:11 | Burn-Rate-Alert alarmiert die Rufbereitschaft. |
| 14:18 | Trace-Analyse zeigt Requests, die auf Pool-Verbindungen warten; das Deployment fällt zeitlich mit dem Beginn zusammen. |
| 14:21 | Rollback gemäß Checkout-Runbook gestartet. |
| 14:27 | Latenz und Fehler wieder auf Baseline-Niveau; Incident eingedämmt. |
Aus dieser Zeitlinie ergeben sich die Zeit bis zur Erkennung (9 Minuten vom Deployment bis zum Alert) und die Zeit bis zur Eindämmung (25 Minuten), die in das MTTR-Tracking einfließen. Mögliche Maßnahmen: Pool-Größe in der CI validieren, eine Canary-Stufe mit automatischem Rollback und ein Sättigungs-Alert auf den Pool.
Best Practices
- Schreiben Sie den Entwurf innerhalb weniger Tage, solange Erinnerungen, Chatverläufe und Telemetrie frisch sind.
- Verlinken Sie Belege direkt: Dashboards, Traces, Log-Abfragen, Deployment-Einträge, Chat-Protokolle.
- Bevorzugen Sie Maßnahmen, die das System verändern (Leitplanken, Automatisierung, Tests), statt Menschen zu mehr Vorsicht aufzufordern.
- Prüfen Sie offene Maßnahmen regelmäßig; ein unerledigtes Postmortem ist ein Versprechen, das der nächste Incident einlöst.
- Teilen Sie Postmortems breit und machen Sie sie durchsuchbar, damit andere Teams wiederkehrende Muster erkennen.
Das Review-Meeting moderieren
Zuerst entsteht der schriftliche Entwurf; das Meeting dient Rückfragen, nicht dem Vorlesen des Dokuments. Laden Sie die Beteiligten der Incident-Reaktion, die Verantwortlichen der betroffenen Services und eine Person ein, die nicht involviert war, denn Außenstehende stellen die Fragen, die Insidern nicht mehr auffallen. Eine neutrale Moderation hält die Diskussion bei Mechanismen statt bei Personen und beendet Debatten darüber, wer es hätte besser wissen müssen. Am Ende stehen priorisierte Maßnahmen mit klaren Verantwortlichen. Veröffentlichen Sie bei schweren Incidents zusätzlich eine kurze Zusammenfassung für Kunden, idealerweise auf derselben Statusseite, die Sie während des Incidents genutzt haben.
Typische Fehler
- Beim ersten technischen Auslöser aufhören, statt zu fragen, warum die Schutzmechanismen ihn nicht abgefangen haben.
- Lange Listen vager Maßnahmen ohne Verantwortliche erstellen.
- Beinahe-Incidents auslassen, obwohl sie besonders günstige Lektionen liefern.
- Die Zeitlinie aus dem Gedächtnis schreiben, statt sie aus Telemetriedaten zu rekonstruieren.
Wie Obseria unterstützt
Obseria bündelt Alerts, Deployments, Traces, Logs und Chat-Aktivität auf einer Zeitlinie. So entsteht der faktische Teil eines Postmortems aus Belegen statt aus Erinnerungen. Obseria Intelligence dokumentiert seine Root-Cause-Analyse als Beweiskette, die Sie direkt in das Review übernehmen können, und Incident-Daten lassen sich zur Nachverfolgung mit ServiceNow synchronisieren.