Post-Incident-Analysen

1) Warum Post-Incident-Analysen erforderlich sind

Post-Mortem/AAR (Post-Mortem/AAR) ist ein strukturierter Lernprozess einer Organisation nach einem Ausfall. Das Ziel ist nicht die Suche nach Schuldigen, sondern die Identifizierung von Wurzelursachen und beitragenden Ursachen und die Verankerung messbarer Maßnahmen (CAPAs), die das Risiko einer Wiederholung und die Kosten von Vorfällen reduzieren, indem sie SLO, MTTR und das Vertrauen der Kunden/Aufsichtsbehörden verbessern.

2) Prinzipien (Just Culture)

Keine Vorwürfe: Wir analysieren Systeme, Entscheidungen und Zusammenhänge, nicht Persönlichkeiten.
Fakten sind wichtiger als Meinungen: Zeitlinien, Protokolle, Metriken, Traces, Artefakte der Veränderung.
E2E-Look: von Symptomen beim Kunden über interne Abhängigkeiten bis hin zu externen Anbietern.
Überprüfbarkeit: Jede Hypothese wird durch ein Experiment/Daten bestätigt.
Zyklusschluss: Analyse → CAPA → Checkpoints → Retest.

3) Wann die Analyse gestartet wird und welche Formate es gibt

Obligatorisch: SEV-0/1; Verstoß gegen SLA/regulatorische Anforderungen; Datenleck; Ein großes PR-Risiko.
Beschleunigt (Licht): SEV-2 mit spürbarem Einfluss oder wiederkehrenden Symptomen.
Kommunikation AAR: Wenn der Fehler die Status-Seite/den Support betrifft, überprüfen Sie die SLAs der Updates und die Qualität der Nachrichten.

Fristen: Entwurf 48-72 Stunden, endgültige Version - bis zu 5 Werktage (sofern nicht anders vereinbart).

4) Rollen und Verantwortung

Parsing Owner (RCA Lead): Organisiert den Prozess, leitet das Meeting, ist für die Qualität des Berichts und der CAPA verantwortlich.
Incident Commander (IC): Liefert die Faktenlage des Vorfalls und der Lösung.
Tech Leads (nach Systemen): Analyse der Ursachen, die Artefakte bestätigen.
Comms/Support/Legal: Bewertung von Kommunikations- und Compliance-Anforderungen.
Scribe: Protokoll, Beweisaufnahme, Einhaltung der Struktur.
Produkt/Geschäft Stakeholder: Auswirkungen auf Kunden/Umsatz, CAPA Priorisierung.

5) Vorbereitung: Was vor dem Treffen zu sammeln

Zeitlinie (UTC): T0 Erkennung → Tn Wiederherstellung; releases/fitch flags/configs, Status der Anbieter.
Beobachtungsdaten: SLI/SLO-Diagramme, Fehlerrate, Perzentile, Protokolle, Traces, Screenshots.
Kontext der Veränderung: Links zu PR/Deploy, DB-Migrationen, Fitch-Flags, Arbeitspläne.
Impact: betroffene Kohorten/Regionen/Anbieter, Ausfallminuten, SLA-Credits.
Mitteilungen: Entwürfe/Beiträge auf der Statusseite, Antworten von saport, interne Ankündigungen.
Politiker/Playbooks: Was hätte im Prozess passieren sollen, wo es Abweichungen gab.

6) Analysemethoden (wählen Sie eine Kombination)

5 Warum: schnelles Öffnen der kausalen Kette (Risiko - übermäßige Vereinfachung).
Ishikawa-Diagramm (Fishbone): Menschen/Prozess/Plattform/Politik/Partner/Produkt.
Fault Tree Analysis (FTA): Deduktion von einem Ereignis zu einer Vielzahl von Ursachen (AND/OR).
Änderungsanalyse: Was hat sich während des Vorfalls verändert vs stabiler Zustand.
Causal Graph: Kausalgraph für komplexe Microservices und externe Abhängigkeiten.
Human Factors Review: Müdigkeit, Informationslärm, irrelevante Runbooks.

7) Berichtsstruktur (Vorlage)

1. Zusammenfassung (Executive Summary): Was, wann, wer beeinflusst wurde, ist der endgültige Status.
2. Impact: SLI/SLO, Benutzer, Regionen/Anbieter, minimale Ausfallzeiten, finanzielle/regulatorische Auswirkungen.
3. Zeitleiste (UTC): Schlüsselereignisse, Releases, IC-Lösungen, Kommunikation.
4. Beobachtungen und Daten: Diagramme, Protokolle, Traces, Diffuse Config/Schemata.
5. Hypothesen und Tests: akzeptiert/abgelehnt, Verweise auf Experimente/Simulationen.
6. Wurzelursachen: systemisch/prozessual/technisch (klare Formulierung).
7. Beitragende Faktoren: Warum nicht früher bemerkt/gestoppt.
8. Was funktionierte/was nicht funktionierte: Prozesse, Werkzeuge, Menschen.
9. CAPA: Korrektur- und Vorbeugungsmaßnahmen mit Eigentümern/Deadlines/Erfolgsmetriken.
10. Prüfplan: Prüfpunkte D + 14/D + 30, Abschlusskriterien.
11. Versionen für Externe: Client/regulatorisch (keine sensiblen Daten).
12. Anwendungen: Artefakte, Links zu Tickets/PR, Screenshots von Dashboards.

8) CAPA: Wie man Handlungen zu Arbeitern macht

Jede Aktion hat einen Besitzer, eine Deadline und einen Effekt-KPI (z.B. Reduktion der Change-Failure-Rate um X%, Null-Wiederholung 90 Tage, Reduktion der Burn-Rate in Peaks).
Trennen Sie Corrective (korrigieren) und Preventive (verhindern) Maßnahmen.
Binden Sie an Policy-as-Code: Alerts, SLO-Gates, Autoscale/Limits, GitOps.
Die CAPA landet im öffentlichen Backlog mit Reviews bei den wöchentlichen Betriebsbesprechungen.

9) Wirkungsprüfung und Schließung

Kontrollpunkte: D + 7 (intermediär), D + 14/D + 30 (primär), D + 90 (Summe).
Verifikation: Tests/Simulationen (Spieltag), Schattenverkehr, Beobachtbarkeit (stabile SLI im grünen Bereich), kein Rückfall.
Der Abschluss ist nur möglich, wenn CAPAs durchgeführt und Metriken bestätigt wurden.

10) Kommunikation und Compliance

Intern: Verständlicher Status für Produkt/Support/Management, SLA-Updates werden eingehalten.
Extern: Status-Seite, Mailings an Kunden/Partner; Sprache ohne Vorwürfe, klarer Präventionsplan.
Regulatorisch: Meldefristen, Depersonalisierung von Beispielen, unveränderliche Speicherung von Berichten und Artefakten.

11) Prozessreifemetriken

Veröffentlichungszeit des Berichts: Fakt vs SLA (z. B. ≤5 Arbeitstage).
CAPA-Abschlussrate:% der Aktivitäten, die rechtzeitig abgeschlossen wurden.
Reopen Rate: Anteil der Wiederholungsvorfälle in 90 Tagen.
Anteil systemischer Ursachen gegen „menschliches Versagen“.
Alert-Hygiene: Reduzierung von falschen Pages, Wachstum von Runbook 'ami-beschichteten Alerts.
Änderung der DORA-Metriken: MTTR, Change-Failure-Rate vorher/nachher.

12) Checklisten

Vor der Analyse

• Der RCA-Eigentümer und die Zusammensetzung der Teilnehmer sind definiert.
• Gesammelte Zeitlinien und Artefakte (Protokolle/Grafiken/Releases/Flags).
• Impact nach Kohorten/Region/Anbieter bewertet.
• Entwürfe der Abschnitte „Impact“ und „Timeline“ wurden erstellt.
• Relevante Richtlinien/Playbooks werden den tatsächlichen Aktivitäten zugeordnet.

Während der

• Akzeptierte/abgelehnte Hypothesen und Basen werden festgehalten.
• Wurzel- und beitragende Ursachen werden identifiziert.
• CAPA-Plan mit KPIs und Fristen erstellt.
• Versionen des Berichts für Externe (falls erforderlich) vereinbart.

Nach

• Bericht rechtzeitig veröffentlicht, Zugriff nach Rolle.
• CAPAs sind im Backlog eingetragen, Besitzer bestätigt.
• Checkpoints und Mini-Simulation zur Überprüfung zugewiesen.
• runbook/SOP/alerts/documentation aktualisiert.

13) Anti-Muster

„Mann X ist schuld“ - ohne systemische Gründe → eine Wiederholung.
Bericht ohne CAPA oder ohne Eigentümer/Fristen - Papier für Papier.
Keine Fakten/Artefakte - Schlussfolgerungen auf Empfindungen.
Eine zu gemeinsame Sprache („OBD-Überlastung“) ohne konkrete Änderungen.
Missachtung von Kommunikation und Compliance sind Reputationsrisiken.
Schließungen ohne Wirkungsprüfung - Rückfälle nach Wochen.

14) Mini-Vorlagen

Berichtskopf

Incident: INC-2025-10-31 (SEV-1)
Window: 2025-10-31 18: 05-18: 47 UTC
Owner of the analysis: @ rca-lead
Affected: EU region, payments (success -28% peak)
Status: corrected; 48 hours monitoring

Formulierung der Wurzelursache (Beispiel)

CAPA (Fragment)

Aktivieren Sie das kanarische Routing zu PSP-A (1%→5%→25%), Eigentümer: @ payments-tl, bis: 2025-11-07, KPI: Null P1-Vorfälle bei 30-tägigen Provider-Releases.
Timeouts/Retrays mit Gesamtzeit neu konfigurieren ≤ SLA 800 ms, Besitzer: @ platform-sre, bis: 2025-11-05, KPI: p99 <600 ms unter Last N.
Business SLI nach BIN-Kohorten hinzufügen, Besitzer: @ data-lead, bis: 2025-11-10, KPI: Erkennung von Degradationen <5 min.

15) Einbettung in die tägliche Praxis

Wöchentliche RCA-Reviews: CAPA-Status, neue Lektionen, Prozessupdates.
Verzeichnis der Post-Mortems im Wiki mit Tags (Service, SEV, Gründe) und Suche.
Simulationen basierend auf dem Vorfall in 2-4 Wochen zur Überprüfung der Maßnahmen.
Lektionen in On-Call-Onboarding einbeziehen und Lernszenarien aktualisieren.

16) Das Ergebnis

Post-Incident-Analysen sind ein Mechanismus zur systemischen Verbesserung. Wenn Fakten gesammelt, Kausalität bewiesen, Handlungen messbar und verifiziert sind, baut die Organisation Betriebskapital an Zuverlässigkeit auf: MTTR und wiederholte Vorfälle sinken, die Vorhersagbarkeit von Releases und das Vertrauen der Kunden steigt.