Die meisten Postmortems sind Archäologie: ein genaues Protokoll von etwas, das niemand ändern wird. Ein nützliches erzeugt eine kleine Zahl von Dingen, die tatsächlich erledigt werden.
Der Zweck eines Postmortems ist nicht, zu dokumentieren, was passiert ist. Er besteht darin, den nächsten Vorfall unwahrscheinlicher oder weniger schädlich zu machen. Alles im Dokument sollte dem dienen; alles andere ist Zeremonie.
Blameless ist ein Mechanismus, keine Umgangsform
Blameless Postmortems werden oft damit erklärt, dass sie freundlich seien. Das verkauft sie unter Wert. Sie existieren, weil Menschen, die Schuldzuweisungen erwarten, Informationen zurückhalten — und genau diese zurückgehaltene Information hätte eine Wiederholung verhindert.
Eine Struktur, die funktioniert
- Zusammenfassung — drei Sätze: was kaputtging, wie lange, wer betroffen war. Die meisten Leser hören hier auf, sie muss also für sich stehen.
- Auswirkung — Dauer, betroffene Nutzer, Umsatz- oder Datenfolgen, wo möglich in Zahlen
- Zeitleiste — Fakten mit Zeitstempeln, vom ersten Symptom bis zur Behebung, einschließlich des Moments, in dem Menschen es bemerkten
- Beitragende Faktoren — Mehrzahl, und ehrlich auch zu den Prozessfaktoren, nicht nur zum technischen Auslöser
- Was gut lief — wirklich nützlich, um die Erkennung oder Reaktion zu verstärken, die funktioniert hat
- Maßnahmen — jede mit Verantwortlichem und Termin
Die Ursache ist meist eine Geschichte, keine Zeile
«Das Deployment verursachte den Ausfall» ist der Punkt, an dem die Analyse endet, wenn das Meeting hetzt. Echte beitragende Faktoren sehen meist so aus:
| Ebene | Beispielbefund |
|---|---|
| Auslöser | Eine Config-Änderung wurde deployt |
| Warum es brach | Die Änderung war syntaktisch gültig, aber semantisch falsch |
| Warum nichts es abfing | Keine Staging-Umgebung entsprach der Produktions-Config |
| Warum es 40 Minuten dauerte, es zu bemerken | Die Alarmierung beobachtete CPU, nicht die Checkout-Erfolgsrate |
| Warum die Wiederherstellung langsam war | Rollback war für reine Config-Änderungen nie getestet worden |
Vier dieser fünf sind Prozessprobleme. Beheben Sie nur den Auslöser, kehrt dieselbe Klasse von Vorfällen in anderer Kleidung zurück.
Maßnahmen: der Teil, der entscheidet, ob irgendetwas davon zählte
- Maximal drei bis fünf Punkte — eine Liste mit zwanzig ist eine Liste mit null
- Jeder mit einer namentlich genannten Person, nicht einem Team
- Jeder mit einem Termin, verfolgt im selben System wie normale Arbeit
- Bevorzugen Sie Punkte, die eine Fehlerklasse beseitigen (eine Leitplanke), gegenüber solchen, die eine Instanz beheben
- Prüfen Sie sie beim nächsten Postmortem — unerledigte Punkte vom letzten Mal sind der wichtigste Tagesordnungspunkt
Ein Postmortem, das bis zum nächsten Vorfall keine erledigten Maßnahmen hat, ist kein Prozess. Es ist eine Ablagegewohnheit.
Zeitpunkt und Publikum
- Entwurf innerhalb von 48 Stunden — Genauigkeit verfällt schnell
- 30–45 Minuten treffen, nicht länger; das Dokument leistet die meiste Arbeit
- Alle Beteiligten einbeziehen, plus eine Person, die nicht dabei war (sie stellt die naheliegenden Fragen, die Insider überspringen)
- Breit teilen — interne Transparenz über Fehler ist der Weg, wie Organisationen darin besser werden
Vorbeugende Maßnahmen überprüfbar abschließen
Ein Postmortem soll Verhalten oder Kontrollen ändern. Jede Maßnahme braucht einen Erfolgsnachweis zusätzlich zum Termin.
- Fakten, Hypothesen und beitragende Bedingungen trennen.
- Jede Maßnahme mit dem adressierten Fehlermechanismus verbinden.
- Änderungen durch Test, Alarmübung oder Wiederherstellungsprobe bestätigen.
Häufige Fragen
Wie bald nach einem Vorfall sollte ein Postmortem stattfinden?
Entwurf innerhalb von 48 Stunden, Treffen innerhalb einer Woche. Die Erinnerung an exakte Abfolge und Begründung verfällt schnell, und die wichtigsten Details — was jemand damals glaubte und warum — verschwinden zuerst.
Was macht ein Postmortem in der Praxis blameless?
Zu fragen, wie das System den Fehler zuließ, statt wer ihn verursachte. Praktisch: keine Namen an Fehlern im Dokument, Fragen über Mechanismen statt über Entscheidungen, und Maßnahmen, die Leitplanken einziehen, statt Menschen zu bitten, vorsichtiger zu sein.
Wie viele Maßnahmen sollte ein Postmortem erzeugen?
Drei bis fünf, jede mit benanntem Verantwortlichen und Termin. Längere Listen sind ein verlässliches Zeichen dafür, dass nichts geschehen wird — und unerledigte Punkte sollten der erste Tagesordnungspunkt beim nächsten Review sein.
Wann ist eine Postmortem-Maßnahme abgeschlossen?
Wenn der vereinbarte Nachweis vorliegt und geprüft wurde. Ein geschlossenes Ticket oder ein aktualisiertes Dokument beweist nicht automatisch verändertes Systemverhalten.
Wiederholen sich Ihre Vorfälle?
Das ist ein Prozessproblem, kein Pechproblem. Wir auditieren Delivery- und Incident-Praxis und reparieren den Mechanismus.
Weiterführend
Produktionsausfall bewältigen: Ein Playbook für kleine Teams
Bei einem Ausfall ist das technische Problem selten der schwierige Teil. Die Koordination ist es. Dies ist die Reihenfolge, die ein kleines Team davon abhält, alles schlimmer zu machen.
Audit der Engineering-Prozesse: Was wir prüfen und warum
Wenn ein Team langsam liefert, liegt die Ursache fast nie bei den Entwicklern. Es sind meist vier oder fünf konkrete Reibungspunkte, die niemand gemessen hat.