Root Cause Analysis

1) Was ist RCA und warum ist es notwendig

Root Cause Analysis ist ein strukturierter Prozess zur Identifizierung der Wurzelursachen eines Vorfalls, um eine Wiederholung auszuschließen. Im Zentrum stehen Fakten, kausale Zusammenhänge und systemische Verbesserungen (Prozesse, Architektur, Tests), nicht die Suche nach Schuldigen.
Ziele: Rückfall verhindern, MTTR/Häufigkeit von Vorfällen reduzieren, SLO verbessern, Vertrauen von Regulierungsbehörden und Partnern aufbauen.

2) Prinzipien (Just Culture)

Ohne Anklage. Wir bestrafen nicht Menschen, sondern risikoreiche Praktiken.
Faktizität. Nur überprüfbare Daten und Artefakte.
E2E-Look. Vom Kunden über das Backend bis hin zu den Anbietern.
Überprüfbarkeit von Hypothesen. Jede Aussage ist mit einem Test/Experiment.
CAPA-Verschluss. Korrektur- und Vorbeugungsmaßnahmen mit Eigentümern und Fristen.

3) Input Artefakte und Vorbereitung

Zeitlinie UTC: T0 Erkennung → T + Aktion → T + Wiederherstellung.
Beobachtungsdaten: Protokolle, Metriken (einschließlich nach Kohorten), Traces, Synthetik, Status-Seite.
Änderungen: Releases, Fitch Flags, Configs, Provider Events.
Umgebung: Versionen, Hash-Artefakte, SBOMs, Infrastruktur-Tags.
Incident Base: Impact Description (SLO/SLA, Kunden, Umsatz), getroffene Entscheidungen, Workaround 's.
Chain of custody: Wer und wann Beweise gesammelt/geändert hat (wichtig für Compliance).

4) RCA-Techniken: wann welche

1. 5 Warum - Finden Sie schnell die kausale Kette für enge Probleme heraus. Das Risiko: ein komplexes System zu einem Lineal „zusammenzurollen“.
2. Ishikawa-Diagramm (Fishbone) - Ordnen Sie die Faktoren in Kategorien: Menschen/Prozess/Plattform/Politik/Partner/Produkt. Hilfreich am Anfang.
3. Fault Tree Analysis (FTA) - Deduktion von einem Ereignis zu einem Satz von Ursachen (AND/OR). Für Infrastruktur und Ausfälle „auf Holz“.
4. Causal Graph/Event Chain ist ein Abhängigkeitsgraph mit Wahrscheinlichkeiten und Gewicht des Beitrags. Gut für Microservices und externe Anbieter.
5. FMEA (Failure Modes & Effects Analysis) - Prävention: Fehlermodi, Schweregrad (S), Häufigkeit (O), Nachweisbarkeit (D), RPN = S × O × D.
6. Change Analysis - Vergleich „wie es war/wie es wurde“ (diff config, schema, Versionen).
7. Human Factors Review - Kontext menschlicher Entscheidungen (Alert-Müdigkeit, schlechte Playbooks, Überlastung).

Empfohlene Bundle: Fishbone → Change Analysis → Causal Graph/FTA → 5 Warum auf die wichtigsten Zweige.

5) Schritt für Schritt RCA-Prozess

1. Initiieren: RCA-Besitzer zuweisen, Frist für Berichtsfreigabe festlegen (z.B. 5 Arbeitstage), Team zusammenstellen (IC, TL, Scribe, Vertreter der Anbieter).
2. Sammeln Sie Fakten: Zeitlinien, Grafiken, Veröffentlichungen, Protokolle, Artefakte; Versionen und Kontrolle der Beträge zu erfassen.
3. Kartierung der Auswirkungen: welche SLI/SLOs betroffen sind, welche Kohorten (Länder, Anbieter, VIPs).
4. Erstellen Sie Hypothesen: primär, alternativ; Welche sind jetzt überprüfbar?
5. Testen Sie Hypothesen: Wiedergabe auf einem Stapel/Simulation/Kanarienvogel, Analyse von Traces, Fault Injection.
6. Identifizieren Sie die Wurzel- und beitragenden Ursachen: technologisch, prozessual, organisatorisch.
7. CAPA bilden: korrigieren (korrigieren) und warnen (verhindern); Erfolgsmetriken und Zeitrahmen.
8. Abstimmung und Veröffentlichung des Berichts: interne Wissensdatenbank + ggf. externe Version für Kunden/Prüfer.
9. Verifizierung der Wirkung: Kontrollpunkte nach 14/30 Tagen; Schließen von Aktionen.

6) Was als „Wurzelursache“ gilt

• schwache Tests/Fitch-Flags, fehlende Limits/Alerts, mehrdeutige Dokumentation, fehlerhafte Defaults, fragile Architektur.
• Oft ist es eine Kombination von Faktoren (Konfiguration × das Fehlen eines Gates × die Belastung × Provider).

7) CAPA: Korrektur- und Vorbeugungsmaßnahmen

• Code/Config-Fix, Pattern-Rollback, Limits/Timeouts ändern, Indizes hinzufügen, Replik/Sharding, Traffic-Sharing, Zertifikate aktualisieren.

• Tests (Contracting, Chaos Cases), Alerts (Burn Rate, Quorum Synthetics), Release Policy (Canary/Blue-Green), GitOps auf Configs, Training/Checklisten, Anbieterduplizierung, DR-Übungen.

Zu jeder Aktion: Besitzer, Deadline, erwarteter Effekt, Validierungsmetrik (z.B. Reduktion der Change-Failure-Rate um X%, keine Wiederholungen 90 Tage).

8) Verifikation von Hypothesen und Effekten

Experimente: Fault Injection/Chaos, Shadow-Traffic, A/B Config, Load mit realen Profilen.
Erfolgsmetriken: SLO-Wiederherstellung, p95/p99-Stabilisierung, keine Fehler-Rate-Spikes, MTTR-Reduktion, Burn-Rate und Zero-Reopen-Trend für 30 Tage.
Prüfpunkte: D + 7, D + 30, D + 90 - Überprüfung der CAPA-Ausführung und des Einflusses.

9) RCA-Berichtsvorlage (intern)

1. Kurzzusammenfassung: Was wann geschah, wer betroffen war.
2. Impact: SLI/SLO, Nutzer, Regionen, Umsatz/Strafen (falls vorhanden).
3. Zeitlinie (UTC): wichtige Ereignisse (Alerts, Lösungen, Releases, Fixes).
4. Beobachtungen und Daten: Diagramme, Protokolle, Traces, Configs (Diffs), Provider-Status.
5. Hypothesen und Tests: akzeptiert/abgelehnt, Verweise auf Experimente.
6. Wurzelursachen: technologisch, prozessual, organisatorisch.
7. Beitragende Faktoren: „warum nicht bemerkt/gestoppt“.
8. CAPA-Plan: Aktionstabelle mit Eigentümern/Deadlines/Metriken.
9. Risiken und Restschwachstellen: Was sonst noch überwacht/getestet werden muss.
10. Anwendungen: Artefakte, Links, Grafiken (Liste).

10) Beispiel (kurz, zusammengefasst)

Ereignis: 35% Rückgang des Zahlungserfolgs um 19: 05-19: 26 (SEV-1).
Impact: 21 Minuten verletzt e2e-SLO, 3 Länder betroffen, Rückerstattungen/Entschädigungen.
Grund 1: Die neue Version des Kartenvalidierers hat die Latenz auf 1 erhöht. 2 mit → Timeouts zum Anbieter.
Grund 2 (Prozent): Für den Anbieter „A“ fehlte der Canary, die Freigabe erfolgte sofort zu 100%.
Grund 3 (org): Die Alert-Schwelle nach Business SLI umfasste keinen bestimmten BIN-Bereich (VIP-Kohorte).
CAPA: alte Version des Validierers zurückgeben; Geben Sie canary 1/5/25%; Hinzufügen eines Business-SLI für BIN-Kohorten; einen Ausfall von 30% beim Anbieter „B“ zu vereinbaren; Chaos-Fall „slow upstream“.

11) RCA-Prozessreifemetriken

CAPAs rechtzeitig ausführen (% geschlossen in 30 Tagen).
Reopen Rate (Vorfälle, die innerhalb von 90 Tagen wiederentdeckt werden).
Change-Failure-Rate vorher/nachher.
Anteil der Vorfälle, bei denen systemische Ursachen gefunden wurden (und nicht nur „menschliches Versagen“).
Testabdeckung für neue Szenarien von RCA.
Zeitpunkt der Veröffentlichung des Berichts (SLA der Publikation).

12) Besonderheiten regulierter Domains (Fintech/iGaming etc.)

Berichterstattung nach außen: Client/regulatorische Versionen des Berichts ohne sensible Details, aber mit einem Plan zur Vermeidung von Wiederholungen.
Audit-Log und Unveränderlichkeit: Aufbewahrung von Artefakten, signierte Berichte, Verknüpfung mit Tickets, CMDBs, Release-Logs.
Benutzerdaten: Depersonalisierung/Maskierung in Logbeispielen.
Kündigungsfristen: Bindung an Verträge und Vorschriften (z.B. N Stunden für Erstmeldung).

13) Anti-Muster

„Vasya ist schuld“ - ein Stopp auf den menschlichen Faktor ohne systemische Gründe.
Fehlende Hypothesentests - Schlussfolgerungen aus der Intuition.
Zu allgemeiner RCA („Service war überlastet“) - keine konkreten Änderungen.
Keine CAPA oder keine Eigentümer/Fristen - Bericht um des Berichts willen.
Ausblenden von Informationen - Vertrauensverlust, Unfähigkeit, die Organisation zu trainieren.
Übersteuern Sie Metriken ohne Verknüpfung mit SLO/Business SLI.

14) Werkzeuge und Praktiken

RCA-Speicher (Wiki/Wissensbasis) mit Metadaten: Service, SEV, Ursachen, CAPA, Status.
Vorlagen und Bots: Generieren eines Berichtsrahmens aus einem Vorfall (Timeline, Charts, Releases).
Kausalitätsgraph: Aufbau einer Ereignis-Kausalkarte (z.B. auf Basis von Logs/Traces).
Chaos-Katalog: Szenarien zur Reproduktion vergangener Vorfälle im Stage.
Dashboards „nach RCA“: separate Widgets, die den CAPA-Effekt bestätigen.

15) Checkliste „bereit zur Veröffentlichung“

• Timeline und Artefakte sind vollständig und verifiziert.
• Wurzelursachen werden durch Tests/Experimente ermittelt und nachgewiesen.
• Wurzel- und beitragende Ursachen sind getrennt.
• CAPA enthält Eigentümer, Timing, messbare Effektmetriken.
• Es gibt einen Verifizierungsplan nach 14/30 Tagen.
• Die Version für externe Stakeholder ist vorbereitet (falls erforderlich).
• Der Bericht hat diese/Prozent-Revue bestanden.

16) Das Ergebnis

RCA ist keine Retrospektive um der Formalität willen, sondern ein Lernmechanismus des Systems. Wenn Fakten gesammelt, Kausalität bewiesen und CAPAs auf Metriken geschlossen und durch Experimente getestet werden, wird die Organisation jedes Mal widerstandsfähiger: SLOs sind stabiler, das Risiko von Rückfällen ist geringer und das Vertrauen der Benutzer und Regulierungsbehörden ist höher.