Meine Session planen

# Session Brief: Root Cause Analysis

## Ziel
Artefakt: Problem Statement

## Arbeitsfrage
Welche systemischen Ursachen haben das Problem verursacht oder ermöglicht, und welche Countermeasures verhindern Wiederholung statt nur Symptom-Behandlung?

## Kontext
Incident-Timeline; relevante Logs und Metriken; verfügbare Postmortems ähnlicher Vorfälle; Symptom-Beschreibung als 1-2-Sätze-Statement; betroffene Kunden oder Systeme.

## Setup
- Format: Methoden-Session
- Dauer: 2-4 h für initiale RCA, danach Folgesitzungen je nach Komplexität
- Modus: Workshop oder async
- Teilnehmende: 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.
- Owner: Ein Facilitator mit Postmortem-Erfahrung
- Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
- Ergebnislogik: Artefakt fertigstellen

## Beteiligungslogik
Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

## Ergebnislogik
Die Session arbeitet direkt auf Problem Statement hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
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.

## Vorbereitung
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.

## Agenda
1. Phase 1: Problem präzisieren (20-30 min)
   Owner: Facilitator
   Aktion: Symptom konkret beschreiben: was, wann, wo, wie oft, welcher Effekt. Impact quantifizieren (Nutzer, Umsatz, Datenintegrität). Abgrenzung gegen ähnliche Probleme. Hinweis: 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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Problem Statement

2. Phase 2: Hypothesen-Fächer (30-45 min)
   Owner: Facilitator
   Aktion: 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. Hinweis: Wenn nur zwei oder drei Hypothesen auftauchen, ist Suche zu eng. Pro Kategorie mindestens eine Hypothese erzwingen, auch wenn unwahrscheinlich. Confirmation Bias vermeiden. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Ursachenhypothesen

3. Phase 3: Hypothesen prüfen (45-90 min)
   Owner: Facilitator
   Aktion: Pro Hypothese Daten suchen: Logs, Metriken, Konfigurationsdiffs, Zeugen. Verifizieren oder Falsifizieren. Verbleibende plausible Hypothesen sind Kandidaten für Root Cause. Hinweis: Wenn pro Hypothese keine Datenquelle benannt werden kann, ist sie spekulativ. Hypothesen-Test ist Kern der Methode. „Plausibel klingen“ ist keine Verifikation. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Bestätigte Ursachen

4. Phase 4: Root Cause(s) festlegen (30-45 min)
   Owner: Facilitator
   Aktion: 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. Hinweis: 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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Maßnahmenplan

5. Phase 5: Countermeasures und Lessons Learned (30-45 min)
   Owner: Owner
   Aktion: Pro Root Cause Countermeasure mit Owner und Datum. Trennen: Symptom-Behebung (Hotfix), Wiederholungsverhinderung (strukturell), Detection (Monitoring). Lessons Learned dokumentieren. Hinweis: 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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Problem Statement

6. Artefakt veröffentlichen (10 min)
   Owner: Owner
   Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
   Output: Problem Statement

## Abschluss
- Ergebnisartefakt aktualisieren: Problem Statement
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# Problem Statement: Root Cause Analysis

## Arbeitsfrage
Welche systemischen Ursachen haben das Problem verursacht oder ermöglicht, und welche Countermeasures verhindern Wiederholung statt nur Symptom-Behandlung?

## Kontext
Incident-Timeline; relevante Logs und Metriken; verfügbare Postmortems ähnlicher Vorfälle; Symptom-Beschreibung als 1-2-Sätze-Statement; betroffene Kunden oder Systeme.

## Beteiligte
- Owner: Ein Facilitator mit Postmortem-Erfahrung
- Teilnehmende: 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.

## Input
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.

## Vorlage
# 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.

## Fertigstellungscheck
- Problem Statement ist vollständig genug für Review:
- Ablageort:
- Version / Status:
- Review durch:
- Nächster Schritt:

## Nächster Schritt
- Ergebnis prüfen
- offene Fragen markieren
- Review oder Entscheidung terminieren