Verwaltung von Vorfällen

(Abschnitt: Technologie und Infrastruktur)

Kurze Zusammenfassung

Incident Management ist ein wiederholbarer Prozess, um den Benutzerwert schnell wiederherzustellen und den Schaden für das Unternehmen zu minimieren. Das Standbein sind klare Rollen (Incident Manager, Tech Lead, Comms), SLO-Gates, Eskalationen, ChatOps-Prozesse, vorbereitete Runabucks und „unschuldige“ Post-Incident-Analysen mit messbaren Action-Items.

1) Ziele und Grundsätze

Schnelligkeit und Sicherheit: Schnelle Diagnose → sichere Stabilisierung → nachhaltige Erholung.
Alleiniger Eigentümer: Der zugewiesene Incident Manager (IM) trifft Prozessentscheidungen.
Kommunikation als Produkt: Berechenbare Upgrades für Stakeholder und Nutzer.
Daten> Meinungen: SLOs/Metriken/Traces/Logs sind die Quelle der Wahrheit.
Blameless: Analyse der Gründe ohne persönliche Anschuldigungen; Fokus auf Systemverbesserungen.

2) Klassifizierung von Vorfällen (Severity/Impact/Urgency)

• SEV1 (kritisch): schwere Schäden an Einnahmen/TTW/Zahlungen,> 20% der Nutzer oder ganze Regionen; SLA gebrochen/PII Bedrohung.
• SEV2 (hoch): teilweiser Abbau von Schlüsselströmen (Einzahlung/Wette/Start von Spielen), Einfluss von 5-20%.
• SEV3 (mittel): spürbare Verschlechterung der sekundären Dienste, Umgehung ist.
• SEV4 (niedrig): Moll, begrenzte Wirkung, keine Auswirkung auf SLO/SLA.

Wirkung: Wer ist betroffen (alle/Region/Tenant/Kanal). Urgency: Degradationsrate (Fast-Burn/Slow-Burn nach Fehlerbudget).

3) Lebenszyklus des Vorfalls

1. Detect - Signal von alert/SLO/synthetics/reports.
2. Acknowledge - on-call bestätigt den Empfang, weist IM zu.
3. Triage - SEV/Impact Auswertung, Hypothesensammlung, Eröffnung des War-Room.
4. Mitigate - die Stabilisierung (der Rücklauf/Umschaltung der Reiseroute/fitscheflagi/Untersetzung).
5. Communicate - regelmäßige Status-Updates (innen/außen).
6. Recover - Vollständige Wiederherstellung von SLO/Business-Metriken.
7. Schließen - Chronologie fixieren, Artefakte sammeln, PIR (RCA + action items).

4) Rollen und Verantwortung (RACI-Schema)

Incident Manager (IM) - Prozessverantwortlicher, weist Rollen zu, überwacht die Zeit, trifft Prozessentscheidungen (R).
Technical Lead (TL) - führt Diagnosen/Hypothesen/Fixes, koordiniert Ingenieure (A/R).
Communications (Comms) - Status-Updates, Kommunikation mit Support/Business/PR, Status-Seite (R).
Scribe - Protokoll (Zeitlinie, getroffene Entscheidungen, Referenzen, Artefakte) (R).
Stakeholders - das Produkt/Zahlungen die Provider/Sicherheit (C/I).

Mindestens SEV1: IM + TL + Comms + Scribe. Im SEV2 ist eine Rollenkombination erlaubt.

5) War-Room и ChatOps

Die einzelnen Kanäle sind:'# incident-warroom- <id>'(arbeitend),'# incident-status'(nur Updates).
Die Musterbefehle lauten: '/incident start', '/status update', '/call <owner>', '/rollback', '/freeze', '/scale + N'.
Der Bot zieht den Kontext hoch: die neuesten Releases, Dashboards, verknüpfte Alerts, Trace-Beispiele, Abhängigkeitsmuster.
Kommunikationsregeln: kurz, sachlich, ein Sprecher (TL), IM moderiert.

6) Trigger und Gates

SLO-Gates: Fast/Slow Burn, sinkende Zahlungsumwandlung, TTW p95> Schwelle, p99 API ↑, Auszahlungswarteschlangen „brennen“.
Auto-Aktivitäten: Stop-Canary, Rollback, Aktivierung des Degrade-Modus (Einschränkung der Funktionen), Einbeziehung von Hochfrequenz-Synthetik.
Freeze: Alle Releases/Stop-Migrationen bis zur Stabilisierung und PIR.

7) Typische Szenarien (Runabuk-Muster)

A) Zahlungen: Steigende Timeouts/Ausfälle bei PSPs

1. Stop promote und Einfrieren von Zahlungskreisfreigaben.
2. Schalten Sie die PSP-Route auf Backup, heben Sie den Timeout/Retrai durch die Politik.
3. Abstimmung unvollständiger Transaktionen, Wiederholung mit idempotenten Schlüsseln.
4. Kommunikation Comms → sapport: Arbeiten Sie Reserve? ETA.

API p99↑ und 5xx nach der Veröffentlichung

1. Blue-Green/Canary → Stable

2. Überprüfen Sie Cache-Treffer, Warteschlangentiefe, DB-Hotspots/Spieleanbieter.
3. Temporäre Skalierung, Begrenzung von schweren Fich durch Feature Flags.

C) Der Spieleanbieter ist nicht verfügbar

1. Schalten Sie den Verkehr auf verfügbare Studios/Spiele, zeigen Sie das Status-Banner.
2. Schließen Sie synthetische Kontrollen alle 30-60s ein.
3. Ausgleich/Boni (nach Politik) vereinbaren - in PIR eintragen.

D) Leck/PII-Verdacht

1. Isolierung der Komponente, Revokation der Schlüssel/Token, Logsammlung (WORM).
2. Harmonisierung der rechtlichen Kommunikation/Regulierung.
3. Post-Incident-Aktionen: Geheimrotation, Maskierung, Zugriffe.

8) Kommunikation (intern/extern)

Häufigkeit der Aktualisierungen: SEV1 - alle 15-30 Minuten, SEV2 - 30-60 Minuten.

• Was kaputt ist: „Einzahlungen über PSP-X: Der Aufstieg der Timeouts“.
• Wer betroffen ist: „TR/BR, ~ 18% der Nutzer des Streams“.
• Wann hat begonnen: „12:07 EET, SEV1.“
• Was wir tun: „Wir wechseln die Route auf PSP-Y, Retrays/Wettlimit sind aktiviert“.
• Das nächste Update: „in 20 Minuten“.
• Kontakt: „IM @ duty-im, TL @ oncall-pay“.

Öffentlicher Status (Seite/soziale Netzwerke) - reduziert, ohne PII und unnötige Details, mit ETA und Link zu weiteren Updates.

9) Sammlung von Artefakten und Audit

Zeitlinie der Ereignisse (Minutengenauigkeit), Versionen der Dienste, Ficha-Flags, Änderungen der Config.
Bilder von Dashboards, Beispielspuren (trace_id), Protokolle „vor/während/nach“.
Links zu Tickets, PR, Releases, Runabucks.
Kommunikationsbericht (wann/an/was).
Alles summiert sich zu einer Karte des Vorfalls.

10) Schließung und PIR (Post-Incident Review)

• Zusammenfassung: Was passiert ist, Umfang, Dauer, SEV.
• Auswirkungen: Benutzer/Regionen, SLO/SLA, Fin. Wirkung.
• Timeline: detailliert, minutengenau.
• Root Cause: technisch + organisatorisch (warum nicht früher deklariert).
• Detections & Defenses: was geholfen/versagt hat (Alerts, Synthetics, Ficheflags).
• Aktionselemente: spezifische Aufgaben, Besitzer, Zeitrahmen (und wie wir die Wirkung testen).
• Lessons Learned: Was wir im Prozess/Architektur/Beobachtbarkeit verändern.

Regeln: keine Vorwürfe, maximale Fakten, obligatorisches Follow-up nach 2-4 Wochen Überprüfung der abgeschlossenen Punkte.

11) Metriken zur Prozesssicherheit

MTTD (Mean Time To Detect) ist die durchschnittliche Erkennungszeit.
MTTA (… Acknowledge) - vor der On-Call-Bestätigung.
MTTR (… Restore) - vor der Wiederherstellung des SLO.
Change Failure Rate -% der Releases, die zu Vorfällen führten.
Incident Rate nach SEV, Verteilung nach Domains (Payments/Games/Infra).
Alert Quality: Anteil laut/falsch, Zeit bis zur Aktion nach der Alert.
Komm-SLA: Einhaltung der Periodizität der Status-Updates.

12) Integration mit SLO und Releases

Gates in CD: Kanarienvogel-Promotion nur mit grünem SLO-Proxy (Verfügbarkeit, p95, conv, TTW).
Freeze-Verfahren: bei fast-burn/SEV1 - Stop-Releases vor PIR.
Auto-Anmerkungen in Graphen: Releases/Flags/Migrationen sind auf Dashboards sichtbar.

13) Regulierung und Compliance

PII: Maskierung/Pseudonymisierung in Logs/Traces, WORM-Audit-Repositories, Zugriffskontrolle.
Regionalität: Nehmen Sie keine Benutzerdaten außerhalb der zulässigen Gerichtsbarkeiten.
Reporting: Formalisierte Briefe/Benachrichtigungen an Regulierungsbehörden - Templates und Eskalationsprozess.

14) Training und Bereitschaft (Game-Day)

Vierteljährliche Übung: „PSP-Tropfen“, „Spieleanbieter nicht verfügbar“, „p99-Spitze“, „Schlüsselleck“.
Timer auf MTTA/MTTR, Retro durch Übungen.
Aktualisieren Sie Runabucks und Kontakte, überprüfen Sie ChatOps-Befehle.

15) Checkliste der Bereitschaft (vor dem Vorfall)

1. SEV-Regeln und Eskalationsmatrix sind vereinbart.
2. Zugewiesene On-Call-Rotationen, IM/TL/Comms/Scribe.
3. Runabuki nach Schlüsselszenarien (Zahlungen, Spiele, DB, Caches, Warteschlangen).
4. SLO-Karte und Burn-Rate Alerts, Status-Seite.
5. ChatOps-Bot: Befehle, Auto-Text, Statusvorlagen.
6. PIR-Vorlagen und Vorfallskarten.
7. Regelmäßige Spieltage und Revisionen von Kontakten/Rechten.
8. Freeze-Richtlinie und „roter Knopf“ (Rollback/Kill-Switch).

16) Antipatterns

Es gibt kein einziges IM, „die Menge führt“ → Chaos und Verzögerungen.
Fehlende SLO-Gates → späte Detektion, laute Alerts.
Veröffentlichung während eines Vorfalls ohne Freeze → Kaskadenfehler.
Logs und Traces reichen nicht aus, es gibt keine Artefakte → einen schwachen PIR.
Schuldkultur → versteckte Fehler, Angst vor Eskalation.
Kommunikation „durch Inspiration“ → Verlust des Vertrauens von Unternehmen/Nutzern.

17) Vorlagen (kopieren Sie in Ihr Wiki)

A) Incident Card (YAML)

yaml id: INC-2025-11-005 title: PSP-X timeouts in TR/BR sev: SEV1 start_at: 2025-11-05T12:07:00+02:00 status: active impact: "Deposits via PSP-X failing for ~18% users (TR, BR)"
im: "@oncall-im"
tl: "@oncall-pay"
comms: "@oncall-comms"
scribe: "@oncall-scribe"
mitigations:
- "Reroute to PSP-Y"
- "Enable retries and raise timeouts"
next_update_in: "20m"
links:
grafana: "<dashboard-url>"
traces: "<tempo-link>"
logs: "<loki-query>"
runbook: "payments/psp_timeout"

B) Status-Aktualisierung (intern)

[12:25] SEV1 PSP-X timeouts — TR/BR
Impact: ~18% deposits affected. SLO fast-burn active.
Mitigation: Rerouting to PSP-Y; retries enabled; release freeze.
ETA next update: 12:45 EET
IM: @oncall-im      TL: @oncall-pay

C) PIR (Cap)

Summary, Impact, Timeline, Root Cause (tech+org),
Detections/Defenses, Action Items (owner+due), Lessons Learned.

Ergebnisse

Ein starkes Incident Management ist Struktur + Disziplin: vordefinierte Rollen, SLO-Gates, geübte Runabucks, transparente Kommunikation und „No-Guard“ PIR. Diese Kontur reduziert MTTA/MTTR, reduziert die Kosten für Ausfallzeiten, stärkt das Vertrauen der Benutzer und ermöglicht es Ihnen, mutiger - aber sicher - zu veröffentlichen.