Simulationen von Vorfällen

1) Warum Simulationen durchführen

• reduzieren MTTD/MTTA/MTTR, erhöhen das Vertrauen in Rollbacks und Failover;
• Erkennen von Prozesslücken (Eskalation, Kommunikation) und architektonischen Schwächen;
• Sie dienen als Einstieg in die RCA→CAPA und verbessern die Dokumentation (Runbook/SOP).
• bestätigen die Bereitschaft zu SLA/Regulatory/Audit-Anforderungen.

2) Simulationsformate

Tabletop (Desktop) - Konversationsszenario auf der Tafel/im Chat: billig, schnell, ideal zum Üben von Rollen und Kommunikation.
Game Day (Übungen in Stage/Prod mit Einschränkungen) - praktische Schritte auf Playbooks; in der Produktion - nur sichere, reversible Aktionen mit klaren Toren.
Chaos Engineering - Managed Failures (Deaktivieren von Abhängigkeiten/Netzwerken/Knoten) zur Überprüfung der Robustheit und SLO-Gates.
DR-Übungen (Disaster Recovery) - AZ/Region-Ausfall, Wiederherstellung aus Backups, Anbieterwechsel.
Comms-drill - reine Kommunikation: Status-Seite, Nachrichtenvorlagen, PR/Legal.

3) Rollen und Verantwortung

Incident Commander (IC) - trifft Entscheidungen, führt einen Plan, Deeskalation.
Tech Lead (TL) - Diagnose, technische „Injektionen“ und Hypothesen.
Comms Lead (CL) - interne/externe Updates, Status-Seite.
Scribe - Protokoll (Zeitlinie, Aktionen, Lösungen, Artefakte).
Beobachter/Gutachter - Erfassen Sie Metriken und die Einhaltung von Verfahren.
Red Team (optional) - führt unvorhergesehene „Injektionen“ ein.

4) Erfolgsmetriken von Simulationen

MTTD/MTTA/MTTR auf einem synthetischen Vorfall.
Comm SLA: Aktualität und Qualität der Upgrades.
SLO-guardrails: korrekte Reaktion auf Burn-Rate, Quorum von externen Proben.
Runbook fidelity:% der Schritte werden nach Dokument ausgeführt, ohne zu improvisieren.
Escalation latency: Geschwindigkeit der Verbindung der gewünschten Rolle/Provider.
Checklisten Pass-Rate: Einhaltung von „bereit/akzeptiert/geschlossen“.
Noise & Fatigue: zusätzliche Alerts, On-Call-Überlastung.
CAPA-Abschluss: Anteil der durchgeführten Aktionen nach der Simulation.

5) Vorbereitung: Was Sie vor dem Start brauchen

Ziel und Hypothesen: Was wir prüfen (Prozesse, Architektur, Menschen).
Szenario und „Injektionen“: eine Abfolge von Symptomen/Ereignissen mit Timings.
Sicherheitsbeschränkungen: Verbot irreversibler Änderungen; Annullierungspunkte.
Daten und Stände: synthetischer Verkehr, Degradationsflaggen, sichere Schlüssel.
Dokumente: Links zum Runbook/SOP, Eskalation, Kontaktliste der Anbieter.
Beobachtbarkeit: Vormarkierte Dashboards/Alerts, Test-Kanarienvögel.
Logistik: Zeit/Dauer, Teilnehmer, War-Room-Kanal, Aufnahme.

6) Durchführung der Simulation: Stufen

1. Brief (5-10 min): IC erinnert an Ziele, Rollen, Sicherheitsregeln, Abschlusskriterien.
2. T0 - Symptominjektion: Alert (s), Business SLI Drop, externer Status des Anbieters.
3. Triage und Eskalation: Zuweisung von SEVs, Freeze-Releases, Anbindung der gewünschten Rollen.
4. Diagnose: Hypothesen, DNS/TLS/CDN/DB/Cache/Bus-Prüfung, Release-Anmerkungen.
5. Mitigierende Aktionen: otkat/kanareyka↓, Ficha-Flags der Degradation, Failover des Providers, Limits/Retrays.
6. Kommunikation: regelmäßige Updates (Format: Impakt→Diagnostika→Deystviya→Sled. Update).
7. Wiederherstellung und Verifizierung: Externe Synthetik + SLI in der grünen Zone der N-Intervalle.
8. Debrief (AAR): 15-30 min - Fakten, Schlussfolgerungen, CAPA.

7) Beispielszenarien (Katalog)

Sinkender Zahlungserfolg: Anbieter A degradiert in einem Land; erwartete Aktionen - Umverteilung des Verkehrs, Einbeziehung einer vereinfachten UX, Kommunikation.
DNS-Fehler: Schreib-/TTL-Fehler, einige Benutzer lösen die Domäne nicht aus; erwartete Schritte - Fixes/Folback, CDN-Bereinigung, Status-Updates.
Abgelaufenes TLS-Zertifikat: Handschlag bricht für alte Kunden; eine Notverlängerung und Überprüfung der Kette wird erwartet.
Kafka lag: Zunahme der Verzögerung bei KYC/AML-Ereignissen; Erwartungen - skalieren Sie die Verbraucher, begrenzen Sie die Produzenten.
DB p99 ↑ und Wachstum 5xx: schmale Indizes, Konnektivitätslimit; Erwartungen - Ficha-Flaggen, Limits, Hotfix/Rollback.
Regionaler Ausfall: Abschaltung von AZ/PoP; Erwartungen - GSLB/Anycast-Umschaltung, Datenvalidierung und SLO.
Kommunikation Drill: Alles ist „grün“, aber wir überprüfen die Muster, Intervalle und Abstimmung mit Legal/PR.

8) „Injection“ -Muster (Karte)

ID: INJ-2025-11-01-01
Purpose: Verification of failover payments and comms SLA
Trigger T0: 30% reduction in transaction success in the TR region (alert SLI + burn rate)
Signals: 5xx growth in payment API, external status PSP-A = partial outage
Expected actions: reduction of the share on PSP-A to 30%, inclusion of degrade-payments-UX, status update 15 min
Success criteria: success of payments ≥ 98% in 30 minutes, two green SLI intervals
NOTAM (security): prohibition of direct database edits; flags/routing only

9) Sicherheit und Compliance

Prod-Simulationen - nur umkehrbar: Fitch-Flags, Traffic-Umschaltung mit kleinen Anteilen, Lesereplikate, „Schattenverkehr“.
Zugangskontrolle/Audit: alle Aktivitäten über ChatOps/Pipeline; Protokolle im unveränderlichen Speicher.
PII/Geheimnisse - werden nicht in Lernartefakten verwendet; Daten werden depersonalisiert.
Regulatory: Wenn die Simulation Kundenkommunikation betrifft - Markierung „Lehre“ in privaten Kanälen; Öffentliche Posts werden nicht nachgeahmt.

10) Bewertung und AAR → RCA → CAPA

AAR (After Action Review) - direkt nach der Übung: Was wurde erwartet/gesehen, was hat funktioniert/nicht.
RCA - für wesentliche Ausfälle (z.B. Eskalation hat nicht funktioniert) nach RCA-Vorlage.
CAPA - Liste der Aktionen mit Eigentümern/Deadlines/Effektmetriken (Änderungen an Playbooks, Alerts, Architektur).
Checkpoints - D + 14/D + 30: Überprüfung der Ausführung, wiederholter Mini-Drill durch Schwachstellen.

11) Dokumentation und Artefakte

Simulationsplan: Ziele, Szenario, Injections, Teilnehmer, Fenster, Erfolgskriterien.
Zeitlinie (UTC): T0...Tn, IC-Lösungen, technische Schritte, Upgrades.
Bilder von Dashboards/Logs, Alertauszügen und Status.
Abschlussbericht: Metriken, Diskrepanzen mit Playbooks, CAPA.
Dokumentationsaktualisierungen: Runbook/SOP/Kontaktbearbeitungen, Links zu neuen Dashboards.

12) Häufigkeit und Reichweite

Tabletop: 2-4 mal pro Monat (nach Key-Streams und Rollen).
Game Days in Stage: 1-2 mal im Monat.
Chaos-Fälle (Prod-Light): vierteljährlich, streng nach Gates.
DR-Übungen: 1-2 mal pro Jahr mit echter Schaltung.
Comms-drill: monatlich für das Training von Vorlagen und SLA-Upgrades.

13) Checklisten

Vor der Simulation

• Szenario, „Injektionen“, Erfolgskriterien, Sicherheitsfenster.
• Rollen, Kanäle, Status der Vorlagen vereinbart.
• Die Verfügbarkeit der Stände/Fahnen/Dashboards wurde geprüft.
• Annullierungs- und Reversibilitätsplan dokumentiert.
• Risiken und Auswirkungen auf SLOs/Kunden bewertet.

Während der

• SEV zugewiesen, freeze releases (falls erforderlich).
• Kommunikation nach Zeitplan, Format gehalten.
• Alle Aktionen über Tools mit Audit.
• Scribe führt ein Protokoll, sammelt Artefakte.
• Sicherheit: Verbote/Beschränkungen werden eingehalten.

Nach

• AAR durchgeführt, Bericht gespeichert.
• RCA (bei Fehlern) eingeleitet.
• CAPAs werden mit Eigentümern/Fristen erstellt.
• Aktualisiert runbook/SOP/Kontakte.
• Ein Retest der Schwachstellen ist geplant.

14) Anti-Muster

„Improvisation statt Plan“ - kein Drehbuch und keine Erfolgskriterien.
Risiken ohne Tore und einen Absageplan - aus der Übung wird ein Vorfall.
Üben Sie nur Technik ohne Kommunikation und Eskalation.
Kein AAR/RCA - Das Team lernt nicht.
Prod-Chaos ohne Beobachtbarkeit und SLO-Gardrails.
Undurchsichtige Rechte: Geheime manuelle Bearbeitungen in der Produktion.

15) Mini-Vorlagen

Spieltagsagenda (60-90 Min)

1. Brief (5 min) → Ziele, Rollen, Sicherheit.
2. Szenario T0 (5 Min.) → Auftreten von Symptomen.

3. Triage/Eskalation (10 Min.)

4. Diagnose + Aktionen (30-45 Minuten) - 1-2 „Injektionen“.

5. Wiederherstellung und Verifizierung (10 Min.)

6. AAR (15 Min.) - Schlussfolgerungen, CAPA.

AAR-Vorlage (kurz)

What was expected:
What happened:
What worked:
What didn't work:
Solutions and why:
Actions (CAPA) with deadlines:
Responsible persons:
Retest Date:

16) Das Ergebnis

Incident Simulationen sind ein „Simulator“ für Menschen, Prozesse und Architektur. Regelmäßige, sichere und messbare Übungen machen Krisen zur Routine: Das Team reagiert schneller, die Playbooks funktionieren tatsächlich, die Architektur ist stabiler und Regler und Kunden sehen die Reife der Betriebsfunktion. Die Hauptsache - klare Ziele, sichere Tore, gute Metriken und obligatorische AAR→RCA→CAPA.