Was vorher fertig sein muss
Eine chronologische Rekonstruktion des Ereignisses mit Zeitstempeln, Signalen, Entscheidungen und Reaktionen liegt vor.
Eine Kultur und ein Format der schuldfreien Aufarbeitung sind etabliert, sodass systemische Ursachen statt Personen adressiert werden.
Was vor Start vorliegen muss
Whiteboard oder digitales Board mit RCA-Vorlage (Problem, Symptome, Hypothesen, Daten, Ursachen, Maßnahmen); Logs, Metriken, Konfigurationsstände; Postmortem-Vorlage; Methodenwerkzeuge wie 5 Whys, Fishbone, Fault Tree zur Auswahl.
Ein Facilitator mit Postmortem-Erfahrung; 4-8 Personen mit direktem Systemkontakt aus Entwicklung, Ops, Support; ein Scribe; bei größeren Incidents zusätzlich ein neutraler Investigator.
Incident-Timeline; relevante Logs und Metriken; verfügbare Postmortems ähnlicher Vorfälle; Symptom-Beschreibung als 1-2-Sätze-Statement; betroffene Kunden oder Systeme.
2-4 h für initiale RCA, danach Folgesitzungen je nach Komplexität
Symptom oben am Board als ein Satz. Verfügbare Methoden auflisten (5 Whys für lineare Kausalität, Fishbone für breite Hypothesenfächerung, Fault Tree für sicherheitskritische Systeme). Postmortem-Vorlage mit Sektionen Problem, Impact, Timeline, Root Cause, Countermeasures, Lessons Learned.
Die eine Frage, die diese Methode beantwortet
Welche systemischen Ursachen haben das Problem verursacht oder ermöglicht, und welche Countermeasures verhindern Wiederholung statt nur Symptom-Behandlung?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Problem präzisieren | 20-30 min | Symptom konkret beschreiben: was, wann, wo, wie oft, welcher Effekt. Impact quantifizieren (Nutzer, Umsatz, Datenintegrität). Abgrenzung gegen ähnliche Probleme. | Wenn Problem-Statement bereits Ursachen enthält („weil X nicht funktionierte“), gehört das in Hypothesen-Phase. Sauberes Symptom ist Basis für nicht-vorgeprägte Suche. |
2Phase 2: Hypothesen-Fächer | 30-45 min | Brainstorming möglicher Ursachen entlang relevanter Kategorien (z. B. Code, Konfiguration, Infrastruktur, Daten, Prozess, Mensch). Fishbone oder Mind Map als Strukturierung. Vermutungen und belegbare Ursachen trennen. | Wenn nur zwei oder drei Hypothesen auftauchen, ist Suche zu eng. Pro Kategorie mindestens eine Hypothese erzwingen, auch wenn unwahrscheinlich. Confirmation Bias vermeiden. |
3Phase 3: Hypothesen prüfen | 45-90 min | Pro Hypothese Daten suchen: Logs, Metriken, Konfigurationsdiffs, Zeugen. Verifizieren oder Falsifizieren. Verbleibende plausible Hypothesen sind Kandidaten für Root Cause. | Wenn pro Hypothese keine Datenquelle benannt werden kann, ist sie spekulativ. Hypothesen-Test ist Kern der Methode. „Plausibel klingen“ ist keine Verifikation. |
4Phase 4: Root Cause(s) festlegen | 30-45 min | Aus verifizierten Hypothesen Root Cause(s) identifizieren. Häufig mehrere Ursachen plus auslösender Faktor. Für jede Ursache prüfen: ist sie steuerbar, ist sie systemisch oder Einzelfall. | Ein einziger Root Cause ist verdächtig. Komplexe Systeme haben meist mehrere zusammenwirkende Ursachen. Häufige Endpunkte „menschliches Versagen“ sind kein Root Cause, sondern Indikator für fehlendes Sicherheitsnetz. |
5Phase 5: Countermeasures und Lessons Learned | 30-45 min | Pro Root Cause Countermeasure mit Owner und Datum. Trennen: Symptom-Behebung (Hotfix), Wiederholungsverhinderung (strukturell), Detection (Monitoring). Lessons Learned dokumentieren. | Wenn alle Countermeasures Monitoring oder Schulung sind, fehlt strukturelle Veränderung. Pro Root Cause mindestens eine Maßnahme, die Wiederholung verhindert, nicht nur Sichtbarkeit verbessert. |
Was am Ende rauskommt
Postmortem-Dokument mit Sektionen Problem, Impact, Timeline, Hypothesen, geprüfte Daten, Root Cause(s), Countermeasures mit Owner und Datum, Lessons Learned. Referenz auf Logs, Metriken und ggf. ergänzende Methoden (5 Whys, Fishbone) als Anhang.
Datum, Incident-ID, Autor und Decider im Header. Spätere Erkenntnisse als Update-Sektion am Ende anhängen, nicht überschreiben. Wenn Root Cause sich später als falsch erweist, Status auf `revised`, ursprüngliche Analyse erhalten.
Kompakte Arbeitsvorlage für Root Cause Analysis mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Root Cause Analysis Arbeitsvorlage
## Ziel
Strukturierte Analyse, um hinter Symptomen die wirksamen Ursachen eines Problems zu finden.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Problem Statement:
- Ursachenhypothesen:
- Bestätigte Ursachen:
- Maßnahmenplan:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## RCA — Incident 2026-05-14-001 Order-API 500er-Spike
**Symptom**: Am 14.05.2026 09:12-09:47 UTC lieferte das Order-API für 8% der Checkout-Requests HTTP 500. Impact: 1.247 fehlgeschlagene Bestellungen, geschätzter Umsatzverlust 18.200 EUR.
### Geprüfte Hypothesen
- Hypothesen-Fächer mit Fishbone: 11 Hypothesen, kategorisiert nach Code, Konfig, Infrastruktur, Daten, Prozess.
- Verifiziert: Connection-Pool-Erschöpfung (Master-DB), ausgelöst durch Batch-Job ohne eigene Pool-Quota.
- Falsifiziert: Hypothese „Hardware-Replica-Defekt“ (Replica zeigte erst Symptome nach Stabilisierung, nicht ursächlich).
### Root Causes
- **Strukturell**: Batch- und Online-Traffic teilen sich denselben Connection Pool ohne Quota-Trennung.
- **Prozessual**: Code Review für Batch-Workloads enthielt keinen Pool-Check, Reviewer übersah die Implikation.
- **Detection**: Pool-Erschöpfung wird nicht alarmiert, erst 500er-Rate.
### Countermeasures
- Eigener Connection Pool für Batch (strukturell). Owner @anna, bis 21.05.
- Checkliste für Batch-Jobs in CODEOWNERS-Review (prozessual). Owner @ben, bis 28.05.
- Pool-Saturation-Alarm in Datadog (detection). Owner @sabine, bis 23.05.
### Lessons Learned
Shared-Resource-Architektur ohne Quota-Trennung ist Klasse von Risiken; ähnliche Muster gibt es bei Worker-Threads und Cache-Slots, Audit angesetzt für 30.06.Symptome erkennen, gegensteuern
RCA endet bei „Engineer hat nicht geprüft“, keine systemische Ursache, keine strukturelle Countermeasure.
Wenn Person als Ursache erscheint, weiter fragen: welches Sicherheitsnetz fehlte. Person ist Symptom, fehlende Checks oder Tools sind Root Cause.
Komplexer Incident wird auf eine Ursache reduziert, andere beitragende Faktoren verschwinden.
Faktoren explizit auflisten: auslösend, beitragend, ermöglichend. In komplexen Systemen sind meist 3-5 Faktoren beteiligt, nicht einer.
Hypothesen werden plausibilitätsbasiert akzeptiert oder verworfen, keine Logs oder Metriken konsultiert.
Pro Hypothese mindestens eine Datenquelle benennen. Wenn keine verfügbar, Hypothese als „unverifiziert“ markieren und Spike für Datensammlung planen, nicht spekulieren.
Maßnahmen sind Monitoring, Alert oder Hotfix, keine strukturelle Veränderung.
Pro Root Cause Pflicht: eine strukturelle Countermeasure (Architektur, Prozess, Tool). Detection separat. Hotfix nur als kurzfristige Stabilisierung mit Folge-Maßnahme.
Erste plausible Hypothese wird zur Wahrheit, andere werden oberflächlich geprüft.
Devil's Advocate beauftragen oder zweite Person paralleler Hypothesen-Fächer. Falsifikationsversuche explizit dokumentieren, nicht nur Verifikationen.
Countermeasures sind dokumentiert, werden aber nicht umgesetzt, gleicher Incident wiederholt sich Monate später.
Countermeasures als Issues im Ticket-System mit Owner und Datum. Status alle 2 Wochen prüfen. Wiederholungs-Incident triggert RCA-Review, nicht neue RCA.
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.