Was vorher fertig sein muss
Eine chronologische Abfolge der Ereignisse mit Zeitstempeln liegt vor, mindestens vom ersten Symptom bis zur Stabilisierung.
Ein etabliertes Postmortem-Setting existiert oder wird in derselben Session genutzt, sodass psychologische Sicherheit als Norm gilt.
Was vor Start vorliegen muss
Whiteboard oder Miro-Board mit vertikaler Kette aus sechs Boxen (Problem + 5 Whys); Stift; Timer; Link zum auslösenden Ticket oder Incident-Report.
Ein Facilitator, der die Kette führt und neutral nachfragt; zwei bis fünf Personen mit direktem Systemkontakt (mindestens ein Engineer, ein Operator); ein Scribe, der jede Antwort wörtlich mitschreibt.
Konkretes Problem als ein Satz mit Datum und Auswirkung; Incident-ID oder Ticket-Link; relevante Logs oder Graphen der letzten 24 Stunden; bekannte Workarounds.
15-30 min
Problem-Satz oben in die erste Box schreiben. Fünf leere Boxen vertikal darunter. Timer auf 20 min. Regel ansagen: keine Namen, nur Mechanismen. Antwort jeder Box wird Ausgangspunkt der nächsten Why-Frage.
Die eine Frage, die diese Methode beantwortet
Welche steuerbare Ursache hinter dem Symptom kann das Team mit einer konkreten Countermeasure beheben?
Marker: Minute
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
10-2 min | 2 min | Problem als beobachtbares Symptom formulieren: was, wann, wie oft, welcher Effekt. Keine Vermutung über Ursache. | Wenn der Satz schon eine Ursache enthält („weil X kaputt war“), neu schreiben. Sonst springt die Kette zu spät ein. |
22-15 min | 13 min | Why-Kette aufbauen: Pro Box eine Why-Frage, eine Antwort, durchgängig auf Mechanismen statt Personen. Nach jedem Why prüfen, ob die Antwort durch Logs oder Daten belegbar ist. | Spätestens beim dritten Why sollte die Antwort technischer oder prozesshafter werden. Bleibt sie auf der Verhaltensebene, fehlt Datenzugang oder Systemkenntnis. |
315-22 min | 7 min | Stoppkriterium prüfen: Ist die unterste Antwort durch das Team selbst änderbar? Wenn nein, einen Why zurückgehen oder den Pfad verzweigen. | Häufig endet eine Kette zu früh bei „der Service ist alt“. Das ist keine steuerbare Ursache; entweder weiter oder zweite Kette parallel. |
422-30 min | 8 min | Eine bis drei konkrete Countermeasures notieren, je mit Owner und Zieldatum. Countermeasure muss die identifizierte Ursache adressieren, nicht das Symptom. | Wenn die Countermeasure „Monitoring verbessern“ lautet, ist es eine Detection-Massnahme, keine Ursachenbehebung. Beides notieren, klar trennen. |
Was am Ende rauskommt
Markdown- oder Wiki-Eintrag im Incident-Verzeichnis mit Problem-Satz, durchnummerierter Why-Kette (Frage und Antwort je Schritt), identifizierter Root Cause und Liste von Countermeasures mit Owner und Datum.
Datum, Incident-ID und Decider im Header. Spätere Korrekturen als Edit-Log am Ende anhängen, nicht überschreiben. Bei neuen Erkenntnissen Status auf `revised` setzen und ursprüngliche Kette behalten.
Kompakte Arbeitsvorlage für 5 Whys mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# 5 Whys Arbeitsvorlage
## Ziel
Einfache Technik, um von Symptomen zu tieferliegenden Ursachen vorzudringen.
## 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
- Root Cause Notes:
- Countermeasures:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Problem
Am 14.05.2026 zwischen 09:12 und 09:47 UTC lieferte das Order-API für rund 8% der Checkout-Requests HTTP 500 zurück.
## Why-Kette
1. Warum 500er? Der Order-Service warf TimeoutException beim Datenbankzugriff.
2. Warum Timeouts? Der Connection Pool war ausgelastet (max 20, in use 20).
3. Warum ausgelastet? Ein neuer Batch-Job hielt 15 Verbindungen für 8 min offen.
4. Warum so lang? Der Job nutzte denselben Pool wie der Online-Traffic ohne eigene Quota.
5. Warum kein Pool-Split? In der Code Review fehlte die Checkliste für Batch-Workloads.
## Countermeasures
- Eigener Connection Pool für Batch (Owner: @anna, bis 21.05.).
- Checkliste für Batch-Jobs in CODEOWNERS-Review ergänzen (Owner: @ben, bis 28.05.).Symptome erkennen, gegensteuern
Antworten enthalten Namen oder Rollen („weil X nicht aufgepasst hat“) statt Systemverhalten.
Antwort umformulieren: was hat das System getan oder unterlassen, das den Fehler ermöglicht hat. Falls Person tatsächlich relevant, frage nach dem fehlenden Sicherheitsnetz im Prozess.
Endantwort ist eine Tatsachenbeschreibung („so war das schon immer“) ohne hebelfähige Stelle.
Mindestens einen Why weiter, oder Kette verzweigen. Wenn nach sieben Whys keine steuerbare Ursache, ist die Methode ungeeignet, A3 oder Causal Loop Diagram nutzen.
Antworten klingen plausibel, sind aber Vermutungen ohne Log-Beleg.
Pro Antwort einen Beleg fordern (Log-Auszug, Graph, Konfig-Zeile). Wenn keiner verfügbar, Why als „unverifizierte Annahme“ markieren und Followup-Spike planen.
Mehrere unabhängige Pfade führen zum Symptom, aber nur einer wird verfolgt.
Bei verdächtiger Verzweigung zweite Why-Kette parallel aufmachen. Beide bis zum Stoppkriterium führen und am Ende Countermeasures kombinieren.
Die abgeleitete Massnahme ist Monitoring, Alarm oder Hotfix, nicht die Ursache aus der Kette.
Detection und Ursachenbehebung getrennt notieren. Pro identifizierter Root Cause mindestens eine Massnahme, die die Wiederholung verhindert, nicht nur die Sichtbarkeit verbessert.
Die Gruppe einigt sich schnell auf eine Antwort, dissidente Stimmen verstummen.
Facilitator fragt explizit nach abweichenden Hypothesen pro Schritt. Bei Uneinigkeit beide Pfade dokumentieren und durch Daten entscheiden.
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.