Run SheetOperationsRoot Cause Analysis

Root Cause Tree Analysis

KomplexitätMedium

Zeit1-3 h

Teilnehmende2-8

FormatWorkshop

MaturityEstablished

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenIncident Timelinenicht im Katalog

Eine chronologische Aufzeichnung der Symptome, Logs und Maßnahmen liegt vor.

Ohne: Ohne Timeline sind Verzweigungen im Baum nicht belegbar, Hypothesen kollabieren in Spekulation.

Vorher abschließenBlameless Postmortem

Die Gruppe arbeitet im blameless Modus, sodass Ursachenpfade systemisch und nicht personell verfolgt werden.

Ohne: Ohne diese Norm engt die Gruppe Pfade vorzeitig ein und stoppt bei Personenfehlern statt Mechanismen.

Vorbereitung

Was vor Start vorliegen muss

Materialien

Whiteboard oder Miro-Board mit Wurzelknoten oben (Problem); Stifte; Haftnotizen in drei Farben (Hypothese, Beleg, Maßnahme); Zugriff auf Logs, Metriken, Konfigurationen; Timer.

Personen / Rollen

Ein Facilitator, der Verzweigungen führt und Belege einfordert; drei bis acht Teilnehmer mit Systemkontakt; ein Scribe für Belegspalte; bei Bedarf ein Daten-Operator, der live Abfragen ausführt.

Vorabinfos

Problemsatz mit Zeitstempel und Auswirkung; bekannte Workarounds; verfügbare Datenquellen; Incident-ID; Liste vermuteter Ursachen aus dem Bauchgefühl der Gruppe.

Zeitbedarf

1-3 h

Setup

Problemsatz oben am Board fixieren. Drei vertikale Zonen vorbereiten (Ebene 1, 2, 3) für Verzweigungstiefe. Regel ansagen: jede Hypothese braucht Beleg, jeder Pfad endet entweder bei steuerbarer Ursache oder bei unverifizierter Annahme.

Kernfrage

Die eine Frage, die diese Methode beantwortet

Welche kausalen Pfade führen vom beobachteten Problem zu steuerbaren Ursachen, und welche Maßnahmen adressieren die wahrscheinlichsten Pfade?

Ablauf

Marker: Phase

Schritt	Dauer	Aktion	Hinweis
1Phase 1: Problem präzise formulieren	10-15 min	Problem als beobachtbares Symptom in einem Satz schreiben: was, wann, wie oft, welcher Effekt. Keine Ursache im Satz. Erfolgsbild für die Analyse formulieren.	Wenn der Satz „weil X“ enthält, ist die Diagnose schon gemacht und der Baum stimmt nicht mehr. Neu formulieren.
2Phase 2: Ursachen verzweigen	30-60 min	Pro möglicher Ursache eine Verzweigung. Auf Ebene 1 die Hauptkategorien (z. B. Software, Daten, Infrastruktur, Prozess). Auf Ebene 2 und 3 konkrete Hypothesen.	Mindestens drei Hauptzweige verlangen, sonst wird der Baum einseitig. Wenn ein Zweig leer bleibt, explizit als „bewusst leer“ markieren mit Begründung.
3Phase 3: Belege ergänzen	30-45 min	Pro Hypothese gelben Beleg-Sticker kleben: Log, Graph, Konfig-Zeile oder Test-Ergebnis. Wenn kein Beleg verfügbar, roten „unverifiziert“-Sticker und Spike-Aufgabe notieren.	Belege werden während der Session live geprüft, wenn möglich. Wer den Operator dabei hat, kann viele Hypothesen sofort widerlegen oder bestätigen.
4Phase 4: Priorisieren und Maßnahmen	20-30 min	Pfade nach Wahrscheinlichkeit und Hebel bewerten (z. B. Ampel). Pro Top-Pfad konkrete Maßnahme mit Owner und Datum. Detection-Maßnahmen von Ursachenbehebung explizit trennen.	„Monitoring verbessern“ ist Detection, keine Ursachenbehebung. Beides notieren, klar voneinander trennen.

Artefakt

Was am Ende rauskommt

Form

Cause-Tree-Diagramm als Bild plus strukturiertes Markdown mit Problemsatz, hierarchischer Liste aller Pfade, Belegen pro Hypothese, Bewertung und konkreten Maßnahmen mit Owner und Datum.

Tool-Alternativen

Miro mit Cause-Tree-Template
Whiteboard mit Foto-Export
draw.io oder Excalidraw mit Tree-Layout
Markdown mit eingerückter Hierarchie im Incident-Repo

Versionierung / Ownership

Pro Vorfall eigener Eintrag mit Datum und Incident-ID. Spätere Erkenntnisse als Update-Sektion am Ende; falsifizierte Pfade nicht löschen, sondern als „widerlegt“ markieren mit Beleg.

canvas

Root Cause Tree Analysis Arbeitsvorlage

Kompakte Arbeitsvorlage für Root Cause Tree Analysis mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

# Root Cause Tree Analysis Canvas

## Kontext

Wofür wird die Methode eingesetzt?

## Kernfrage

Welche Frage soll am Ende beantwortet sein?

## Input

Welche Daten, Beobachtungen oder Materialien liegen vor?

## Arbeitsfläche

- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:

## Ergebnisartefakte
- Cause Tree:
- Evidence Notes:
- Countermeasures:

## Offene Fragen

- ...

## Nächster Schritt

Owner, Datum, Erfolgssignal.

Beispielausgabe

Konkret gefülltes Szenario

root-cause-tree-analysis-beispiel.md

markdown

## Cause Tree — Erhöhte 5xx-Rate Order-API (14.05.2026)

**Problem**: Order-API liefert seit 14.05. 09:12 UTC für rund 8% der Checkout-Requests HTTP 500.

**Pfade (Auszug)**:
- Software
  - Recent Deploy (Beleg: Deploy 09:05 von feature/order-validation, ROT — kein direkter Fehler in Logs)
  - Library-Update (Beleg: keine Updates in 48 h, AUSGESCHLOSSEN)
- Daten
  - DB-Pool-Auslastung (Beleg: Grafana zeigt Pool 100% seit 09:10, BESTÄTIGT)
    - Neuer Batch-Job (Beleg: cron lief erstmals 09:10, BESTÄTIGT — Wurzelursache)
- Infrastruktur
  - Network-Latenz (Beleg: P50 stabil, AUSGESCHLOSSEN)

**Maßnahmen**:
- Ursachenbehebung: Eigener Connection Pool für Batch (Owner: @anna, bis 21.05.).
- Detection: Alert auf Pool-Auslastung über 80% für 2 min (Owner: @ben, bis 18.05.).

Was tun

Detection und Ursachenbehebung getrennt führen. Pro identifizierter Ursache mindestens eine Maßnahme, die Wiederholung verhindert, nicht nur Sichtbarkeit erhöht.

Abbruchkriterien

Done-Signale, in unter einer Minute prüfbar

Kein Datenzugang verfügbar, Belege bleiben durchgehend Spekulation.

Symptom ist nicht reproduzierbar oder einmalig, Baum lässt sich nicht testen.

Keine Person mit Systemkontakt anwesend, Hypothesen sind Hörensagen.

Workshop unter 60 min angesetzt, vier Phasen nicht durchführbar.

Problem ist trivial (bekannter Fix), Baum erzeugt nur Bürokratie.

Gruppe weigert sich, alternative Pfade aufzumachen, Analyse wird einseitig.

Run Sheet durchgearbeitet?

Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.

Zum Steckbrief Weitere Methoden