Was vorher fertig sein muss
Eine chronologische Timeline des Incidents mit Zeitstempeln aller relevanten Ereignisse (Alarme, Aktionen, Recoveries) ist erstellt und im Tool abrufbar.
Ein dokumentierter Incident-Verlauf mit benannten Rollen (Incident Commander, Communications, Operations) liegt vor, sodass Beteiligte und Entscheidungen nachvollziehbar sind.
Was vor Start vorliegen muss
Postmortem-Template (Header, Timeline, Impact, Root Cause, Contributing Factors, Action Items, Lessons); geteiltes Dokument; Log-Auszüge und Graphen vom Incident-Tag; Chat-Transkript aus dem Incident-Channel; Liste der Beteiligten.
Facilitator ohne direkte Incident-Beteiligung; Incident Commander des Vorfalls; alle Operatoren mit aktiver Handlung im Verlauf; ein Scribe für das Protokoll; optional ein neutraler Beobachter aus einem anderen Team für Externblick.
Incident-ID, Dauer, Impact in Zahlen (Nutzer, Umsatz, SLO-Verletzung); Timeline-Entwurf 24 h vor Termin; bekannte Workarounds; bisherige Hypothesen aus dem Chat-Verlauf; Datum und Owner des Termins.
60-90 min Workshop, plus 2 h asynchrone Vorbereitung durch Facilitator
Termin maximal 5 Werktage nach Resolution. Template mit Header und Timeline-Skeleton vorab ausfüllen. Regel ansagen: Sprache fokussiert auf Systemverhalten, keine Namen in Ursachenformulierungen. Aufzeichnung optional, aber Konsens vorab.
Die eine Frage, die diese Methode beantwortet
Welche Systembedingungen und Entscheidungspunkte haben den Incident möglich gemacht, und welche konkreten Massnahmen verhindern die Wiederholung?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Timeline-Walkthrough | 20 min | Facilitator liest die Timeline laut vor, Beteiligte ergänzen Lücken, korrigieren Zeitstempel und kennzeichnen Entscheidungspunkte. Keine Diskussion über Ursachen, nur Faktenbasis. | Wenn das Team in Phase 1 in Diskussion rutscht, Facilitator stoppt und schiebt Punkte in Phase 3. Timeline ist Grundlage, nicht Bewertung. |
2Phase 2: Impact-Erfassung | 10 min | Nutzer-Impact, Geschäfts-Impact und SLO-Verletzungen in Zahlen festhalten. Mindestens: Dauer der Beeinträchtigung, Anzahl betroffener Nutzer, geschätzter Umsatz- oder Reputationseffekt. | Zahlen brauchen Quelle. Wenn Schätzungen, dann als Schätzung markieren. Impact treibt Priorität der Action Items. |
3Phase 3: Contributing Factors | 30 min | Beitragende Faktoren in Kategorien sammeln: Technik, Prozess, Organisation, Information. Pro Faktor: was hat das System getan oder unterlassen, was hätte den Verlauf verändert. Sprache neutral halten. | Facilitator unterbricht bei Personifizierungen und formuliert um. Statt „X hat vergessen“ wird daraus „der Prozess hatte keinen Kontrollpunkt“. |
4Phase 4: Action Items | 20 min | Pro Contributing Factor 0-2 Massnahmen mit Owner, Frist und Priorität. Action Items als kleine, ausführbare Tickets, keine Programme. Detection-Massnahmen klar von Ursachen-Massnahmen trennen. | Wenn alle Action Items „bessere Doku“ oder „mehr Training“ sind, fehlt System-Tiefe. Mindestens eine technische Massnahme pro relevantem Faktor. |
5Phase 5: Lessons und Sign-off | 10 min | Drei Lessons Learned formulieren, die andere Teams interessieren könnten. Veröffentlichungs-Format und Adressaten klären. Sign-off durch Incident Commander und Facilitator. | Lessons gehören in den teamübergreifenden Lernkanal, nicht nur in den lokalen Wiki-Ordner. Wenn Lessons nur intern bleiben, fehlt der Multiplikator-Effekt. |
Was am Ende rauskommt
Postmortem-Dokument im Engineering-Wiki mit Header (Incident-ID, Datum, Severity, Dauer), Timeline mit Zeitstempeln, Impact-Zahlen, Contributing Factors in Kategorien, Action Items mit Owner und Frist, Lessons Learned und Sign-off-Block.
Pro Incident ein Dokument mit Incident-ID im Titel. Status-Feld (draft, review, signed-off, follow-up-done). Action-Item-Status wird im Dokument-Header aktuell gehalten. Spätere Erkenntnisse als datierter Anhang, nicht durch Überschreibung.
Vorlage für Lernen, beitragende Faktoren und Maßnahmen nach einem Incident.
# Blameless Postmortem
## Zusammenfassung
Was ist passiert, welche Wirkung hatte es?
## Impact
- Kundenauswirkung:
- Dauer:
- Betroffene Systeme:
## Timeline
Link oder Auszug der Timeline.
## Beitragende Faktoren
- ...
## Was lief gut?
- ...
## Was verbessern wir?
| Maßnahme | Owner | Datum | Erwartete Wirkung |
|---|---|---|---|
## Follow-up
Review-Termin und Status.Konkret gefülltes Szenario
## Postmortem INC-2026-0847 — Order-API Degradation 14.05.2026
**Severity**: SEV-2. **Dauer**: 35 min (09:12-09:47 UTC). **Impact**: 8,2% der Checkout-Requests mit HTTP 500, geschätzt 1.240 betroffene Nutzer, 14.200 EUR Umsatzverlust laut Finance-Schätzung.
### Timeline
- 09:12 PagerDuty alert SEV-2 auf order-api.error_rate.
- 09:14 @anna übernimmt als Incident Commander.
- 09:21 Batch-Job batch-recon-202 als Korrelation identifiziert.
- 09:33 Batch-Job manuell gestoppt.
- 09:47 Error Rate unter SLO, Incident geschlossen.
### Contributing Factors
- Technik: Batch und Online-Traffic teilen denselben Connection Pool ohne Quota.
- Prozess: Code-Review-Checkliste enthielt keinen Pool-Split-Check für Batch-Workloads.
- Information: Batch-Job wurde am Vortag aktiviert, ohne dass On-Call das wusste.
### Action Items
1. Eigener Connection Pool für Batch-Workloads (Owner: @anna, P1, bis 21.05.).
2. Review-Checkliste um Batch-Pool-Check erweitern (Owner: @ben, P2, bis 28.05.).
3. Slack-Notification für aktivierte Batches an #on-call (Owner: @chris, P3, bis 04.06.).
### Lessons
- Shared Resource Pools sind eine wiederkehrende Schwachstelle, Quota-Strategie teamweit prüfen.
- Batch-Aktivierung muss On-Call sichtbar sein, nicht nur Owner-Team.Symptome erkennen, gegensteuern
Contributing Factors enthalten Namen oder Rollen, das Team rechtfertigt sich statt zu analysieren.
Facilitator schreibt jeden Satz mit Namen sofort um in System-Verhalten. Wer den Faktor verteidigt, wird vom Facilitator zurück in System-Frage geführt.
Zeiten und Aktionen werden im Termin rekonstruiert, Chat-Log oder Pager-Daten werden nicht herangezogen.
Termin nur mit vorbereiteter Timeline starten. Wenn unvollständig, Termin verschieben und Beteiligte mit Chat-Export beauftragen.
Liste enthält Massnahmen wie „besser monitoren“ oder „Doku aktualisieren“ ohne Name und Frist.
Pro Action Item Name und Datum noch im Termin. Ohne Owner ist es kein Action Item, sondern ein Wunsch. Streichen oder neu formulieren.
Dokument bleibt im Draft-Status, Action Items werden nicht verfolgt, dieselbe Klasse Incident wiederholt sich.
Sign-off-Termin spätestens 10 Werktage nach Incident. Action Items ins Backlog mit Label postmortem. Quartalsweises Trend-Review aller offenen Postmortem-Items.
Auch kleinste Glitches bekommen volle Postmortem-Behandlung, Team ist im Postmortem-Marathon.
Severity-Kriterien klar (SEV1-SEV3). Nur SEV1 und SEV2 erhalten Workshop, SEV3 als kurzer schriftlicher Lightweight-Postmortem.
Vorgesetzte oder Kunden lesen mit, Dokument wird verteidigend und unpräzise.
Postmortem bleibt intern, eine separate Stakeholder-Zusammenfassung wird daraus abgeleitet. Trennung von Lerndokument und Kommunikationsartefakt.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.