Ergebnis
Ein blameless Postmortem mit Timeline, beitragenden Faktoren, Maßnahmen und Follow-up.
Playbook
Incident aufarbeiten
Von verstreuten Logs und Erinnerungen zu Timeline, Lernpunkten und konkreten Verbesserungen.
Ideal für
- SRE- und DevOps-Incidents
- kritische Produktionsstörungen
- wiederkehrende operative Probleme
Nicht gut für
- akute Incident-Steuerung
- schuldorientierte Eskalationen
Ablauf
4 SchritteMethodenpfad
- 11DevOpsIncident Timeline
Incident Timeline Analysis
Ereignisse, Signale, Entscheidungen und Lücken chronologisch rekonstruieren.
- 22OperationsCausal Factor Map
Causal Factor Analysis
Beitragende Faktoren statt einzelner Schuldursachen herausarbeiten.
- 33DevOpsPostmortem
Blameless Postmortem
Lernen, Maßnahmen und Verantwortlichkeiten in ein anschlussfähiges Review übersetzen.
- 44OperationsUpdated Runbook
Runbook
Wiederkehrende Response-Schritte in eine klare operative Anleitung überführen.
Vorlagen
Artefakte für dieses Playbook
Markdown
Incident Timeline
Chronologische Vorlage für Incident-Rekonstruktion mit Quellen und Unsicherheiten.
# Incident Timeline
**Incident:** ...
**Zeitraum:** ...
**Quellen:** Logs, Alerts, Chat, Tickets
| Zeit | Ereignis | Quelle | Sicherheit | Notiz |
|---|---|---|---|---|
| HH:MM | | | hoch/mittel/niedrig | |
## Beobachtete Verzögerungen
- ...
## Offene Lücken
- ...
## Lernpunkte
- ...Markdown
Blameless Postmortem
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.Checklist
Runbook Checklist
Checkliste für operative Runbooks mit Trigger, Diagnose, Aktion, Rollback und Eskalation.
- [ ] Trigger klar beschrieben
- [ ] Voraussetzungen und Zugänge genannt
- [ ] Diagnose-Schritte in Reihenfolge
- [ ] Aktionen mit erwarteter Wirkung
- [ ] Verifikation nach jeder kritischen Aktion
- [ ] Rollback oder Stop-Kriterium
- [ ] Eskalationspfad mit Kontakt
- [ ] Letzter Testlauf dokumentiertAbschlusskriterien
- Timeline enthält Zeiten, Quellen und Unsicherheiten.
- Mindestens drei beitragende Faktoren sind beschrieben.
- Maßnahmen haben Owner, Datum und erwartete Wirkung.
- Runbooks oder Alerts wurden konkret angepasst.
- Das Review vermeidet Schuldzuweisung und benennt Systemlernen.