Eskalation der Vorfälle

1) Zweck und Grundsätze

Die Eskalation von Vorfällen ist ein überschaubarer Prozess, um schnell die richtigen Rollen und Ressourcen zu gewinnen, um die Auswirkungen auf Benutzer und Geschäftsmetriken zu minimieren.

• Geschwindigkeit ist wichtiger als Perfektion. Es ist besser, den Vorfall früher zu erklären und zu deeskalieren, als zu spät zu kommen.
• Ein einziges Kommando. Ein Verantwortlicher für die Entscheidung ist der Incident Commander (IC).
• Transparenz. Klare Status und Kommunikationskanäle für interne und externe Stakeholder.
• Dokumentierbarkeit. Alle Schritte, Entscheidungen und Zeitlinien werden für Audits und Verbesserungen erfasst.

2) Abstufung des Schweregrads (SEV/P-Level)

• SEV-0/P0 (kritisch) - vollständige Nichtverfügbarkeit der Schlüsselfunktion (Login/Zahlung), Datenleck, Rechtsrisiko. Sofortige Pages des gesamten Kernels von On-Call, Freeze-Releases.
• SEV-1/P1 (hoch) - Abbau von p95/p99, erhöhte Fehlerquote im Schlüsselprozess, Unzugänglichkeit der Region/des Providers.
• SEV-2/P2 (mittel) - teilweise Degradation für eine begrenzte Kohorte (Region, Anbieter), es gibt einen Workaround.
• SEV-3/P3 (niedrig) - ist für den Benutzer nicht kritisch, erfordert jedoch Aufmerksamkeit (Hintergrundverzögerung ETL, überfälliger Bericht).

• Der Schadensradius (wie viele Benutzer/Umsatz) × die Dauer × die Empfindlichkeit (regulatorisch/PR) → das SEV-Niveau.

3) Prozess-KPIs

MTTD (Detection Time) - vom Beginn des Vorfalls bis zum ersten Signal.
MTTA (Acceptance Time) - vom Signal bis zur IC-Bestätigung.
MTTR (Recovery Time) - bis zur Wiederherstellung der SLO/Funktion.
Escalation Latency - von der Bestätigung bis zur Verbindung der gewünschten Rolle/des Teams.
Reopen Rate - der Anteil der Vorfälle, die nach „gelöst“ wieder geöffnet werden.
Comm SLA - Einhaltung der externen/internen Update-Intervalle.

4) Rollen und Verantwortung (RACI)

Incident Commander (IC): Eigentümer der Lösung, setzt Ebene, Plan, Freeze, Eskalation, Deeskalation. Schreibt keine Fixes.
Tech Lead (TL): Technische Diagnose, Hypothesen, Koordination von Ingenieuren.
Comms Lead (CL): Status-Seiten, Kunden- und interne Kommunikation, Abstimmung mit Legal/PR.
Scribe: genaue Fixierung von Fakten, Zeitlinien, getroffenen Entscheidungen.
Liaisons (Verbindungsleute): Vertreter externer Anbieter/Teams (Payments, KYC, Hosting).
On-Call-Ingenieure: Ausführung des Plans, Ausführen von Playbooks/Rollbacks.

Weisen Sie diensthabende Zeitpläne und Backups für jede Rolle zu.

5) Kanäle und Artefakte

War-Room-Kanal (ChatOps): Einheitlicher Koordinationspunkt (Slack/Teams) mit Auto-Annotation-Vorlage (Versionen, Flaggen, Kanarienvögel).
Videobrücke für SEV-1 +.
Incident Ticket (One-Pager): ID, SEV, IC, Teilnehmer, Hypothese/Diagnose, Schritte, ETA, Status, Impact, Links zu Charts.
Status-Seite: öffentlich/intern; regelmäßige Updates (z. B. alle 15-30 Minuten für SEV-1 +).

6) Zeitboxen und Standardintervalle

T0 (min. 0-5): IC zugewiesen, SEV zugewiesen, Freeze Releases (bei Bedarf), War-Room offen.
T + 15 min: erste öffentliche/interne Meldung (betroffen, Workaround, nächstes Update-Fenster).
T + 30/60 min: Eskalation der nächsten Stufe (Plattform/DB/Sicherheit/Anbieter), wenn keine nachhaltige Dynamik vorhanden ist.
Regelmäßige Aktualisierungen: SEV-0: alle 15 Minuten; SEV-1: alle 30 Minuten; SEV-2 +: jede Stunde.

7) Auto-Eskalationsregeln (Auslöserichtlinien)

• Burn-Rate des Fehlerbudgets über der Schwelle in kurzen und langen Fenstern.
• Quorum von externen Proben: ≥2 Regionen verzeichnen eine Verschlechterung von HTTP/TLS/DNS.
• Der Business SLI (Erfolg von Zahlungen/Registrierungen) fällt unter den SLO.
• Sicherheitssignaturen: Verdacht auf Leck/Kompromittierung.
• Anbietersignal: Webhook-Status „major outage“.

8) Der Prozess von der Entdeckung bis zur Lösung

1. Incident Declaration (IC): SEV, Reichweite, Freeze, Playbook-Start.
2. Diagnose (TL): Hypothesen, Radiusisolation (Region, Provider, Ficha), Prüfungen (DNS/TLS/CDN/DB/Caches/Bus).
3. Mitigierende Aktionen (schnelle Siege): Rollback/Kanarienvogel ↓, Ficha-Flag-Degradierung, Provider-Failover, Rate-Limit, Cache-Overlay.
4. Kommunikation (CL): Status-Seite, Kunden/Partner, Legal/PR, Updates im Zeitplan.
5. Recovery-Bestätigung: Externe Synthetik + Real Metrics (SLI), Freeze-Entfernung.
6. Deeskalation: Abnahme des SEV, Übergang zur Beobachtung N Minuten/Stunden.
7. Closing und RCA: Post-Mortem-Vorbereitung, Aktionsgegenstände, Eigentümer und Zeitrahmen.

9) Zusammenarbeit mit externen Anbietern

Eigene Proben an Anbieter aus mehreren Regionen + gespiegelte Log-Beispiele von Anfragen/Fehlern.
Eskalationsvereinbarungen (Kontakte, Antwort-SLA, Priorität, Status-Webhooks).
Automatisches Failover/Re-Allocation von Traffic über den SLO des Anbieters.
Evidenzbasis: Zeitlinie, Beispielanfragen/-antworten, Latenz-/Fehlerdiagramme, Anbieter-Ticket-ID.

10) Regulierung, Sicherheit und PR

Security/P0: Isolierung, Sammlung von Artefakten, Minimierung der Offenlegung, obligatorische Benachrichtigungen (intern/extern/Regulator).
Legal: Harmonisierung der Formulierung externer Aktualisierungen, Berücksichtigung vertraglicher SLAs/Strafen.
PR/Kundenservice: vorgefertigte Antwortvorlagen, Q&A, Vergütung/Gutschriften (falls zutreffend).

11) Meldungsvorlagen

• "Wir untersuchen einen SEV-1 Vorfall, der [die Funktion/Region] betrifft. Symptome: [kurz]. Wir haben den Workaround [Beschreibung] aktiviert. Das nächste Update ist um [Zeit]"

• "Diagnose: [Hypothese/Bestätigung]. Aktionen: [Provider gewechselt/Release zurückgesetzt/Degradierung aktiviert]. Impact auf [Prozent/Kohorte] reduziert. Das nächste Update ist [Zeit]"

• "Der Vorfall SEV-1 gelöst. Ursache: [root]. Erholungszeit: [MTTR]. Nächste Schritte: [fix/checks/observation N Stunden]. Post-Mortem - [wann/wo]"

12) Playbooks (exemplarisch)

Sinkender Zahlungserfolg: Anteil an Anbieter A reduzieren, X% auf B umrechnen; die Angabe „degrade-payments-UX“; Rückzüge in Limits einbeziehen; Benachrichtigen Sie das Fin-Team.
p99 API-Wachstum: Reduzieren Sie den Kanarienvogel der neuen Version; Schalten Sie die schweren Felder aus; Erhöhung der Cache-TTL; DB-Indizes/Anschlüsse prüfen.
DNS/TLS/CDN Problem: Zertifikate/Kette überprüfen; den Datensatz aktualisieren; auf Backup-CDN umschalten; Sammeln Sie den Cache neu.
Sicherheitsverdacht: Knotenisolation, Schlüsselrotation, Aktivierung von mTLS-Stiften, Sammlung von Artefakten, Benachrichtigung Legal.

13) Deeskalation und Kriterien „beschlossen“

• SLI/SLO stabil in der grünen Zone ≥ N-Intervalle;
• mitigierende Aktionen und Beobachtung durchgeführt - ohne Rückschritt;
• für die Security-Klasse - geschlossene Vektoren bestätigt, Schlüssel/Geheimnisse rotiert.

Die Schließung erfolgt erst nach Festlegung der Zeitlinie, der Besitzer der Aktionsgegenstände und der Fristen.

14) Post-mortem (nicht substantiell)

1. Fakten (Zeitlinie, die Benutzer/Metriken gesehen haben).

2. Wurzelursache (technisch/prozessual).

3. Was bei der Eskalation funktioniert/nicht funktioniert hat.

4. Präventive Maßnahmen (Tests, Alerts, Limits, Architektur).

5. Aktionsplan mit Terminen und Eigentümern.

6. Verknüpfung mit Fehlerbudget und Überarbeitung von SLO/Prozessen.

15) Prozessreifemetriken

Anteil der gemeldeten Vorfälle vor Nutzerbeschwerden.
MTTA nach SEV-Niveau; Zeit, um die gewünschte Rolle zu verbinden.
Einhaltung der Aktualisierungsintervalle (Comm SLA).
Prozentsatz der Vorfälle, die von Playbooks ohne manuelle „Kreativität“ gelöst wurden.
Ausführung von Aktionselementen von Post-Mortems zum Fälligkeitsdatum.

16) Anti-Muster

„Jemand tut etwas“ - keine IC/Rollen.
Vielstimmigkeit im Kriegsraum - Streit um Versionen statt Aktionen.
Späte Erklärung → Zeitverlust, um Leute zu sammeln.
Keine Freeze und Release Annotationen - parallele Änderungen maskieren die Ursache.
Fehlende externe Kommunikation - Eskalation von Beschwerden/PR-Risiko.
Schließen ohne Post-Mortem und Aktionen - wir wiederholen die gleichen Fehler.

17) IC-Checkliste (Taschenkarte)

• Weisen Sie den SEV zu und öffnen Sie den Kriegsraum.
• Weisen Sie TL, CL, Scribe zu, überprüfen Sie den On-Call vorhanden.
• Release-Freeze aktivieren (bei SEV-1 +).
• Bestätigen Sie die Quellen der Wahrheit: SLI Dashboards, Synthetik, Logs, Tracing.
• Ergreifen Sie schnelle Mitigationsaktionen (Rollback/Flags/Failover).
• Regelmäßige Updates nach Zeitplan bereitstellen.
• Fixieren Sie die Kriterien für Resolve und Überwachung nach der Wiederherstellung.
• Initiieren Sie ein Post-Mortem und weisen Sie die Besitzer von Aktionselementen zu.

18) Einbettung in den täglichen Betrieb

Training (Spieltage): Simulationen nach Schlüsselszenarien.
Playbook-Verzeichnis: versioniert, getestet, mit Parametern.
Werkzeuge: ChatOps-Befehle „/declare “, „/page“, „/status “, „/rollback“.
Integrationen: Ticketing, Status-Seite, Post-Mortems, CMDB/Service-Katalog.
Abstimmung mit SLO/Error Budget: Auto-Eskalationsauslöser und Freeze-Regeln.

19) Das Ergebnis

Eskalation ist eine operative Disziplin und nicht nur ein Anruf beim Diensthabenden. Klare SEV-Levels, zugewiesene ICs, vorgefertigte Playbooks, Update-Timeboxen und die Integration mit SLO-Metriken und Budget-Policies verwandeln ein chaotisches Feuer in einen überschaubaren Prozess mit vorhersehbarem Ergebnis - schnelle Service-Recovery, minimales PR/regulatorisches Risiko und Systemverbesserungen nach jedem Vorfall.