Eskalationsmatrix

1) Zweck der Matrix

• SEV-Niveaus und ihre Kriterien;
• Timings (Erkennung von → ack → Eskalation → Upgrades);
• Rollen/Kanäle für jeden Schritt
• Ausnahmen (keine „ruhigen Stunden“ für Sicherheit und Compliance);
• Verknüpfung mit Playbooks und Status-Seite.

2) Klassifizierung nach Schweregrad (SEV)

Geben Sie die Zielzahlen für Ihre Domain und SLO an.

3) Grundlegende Wer/Wann/Wo-Matrix

4) Der entscheidende Baum der Eskalationen (Essenz)

1. Gibt es einen bestätigten Impact auf SLO?

→ Ja: ICs zuweisen, SEVs ankündigen, Kriegsraum eröffnen.
→ Nein: Ticket/Überwachung, keine Seite.

2. Ist das ACK pünktlich?

→ Ja: Weiter geht's mit dem Playbook.

→ Nein: P2 → IC → DM

3. Sicherheit/Leck/PII?

→ Immer Security IR + Legal, öffentliche Kommunikation vereinbart.

4. Externer Anbieter?

→ Eskalation von Vendor Owner, Routenwechsel, Fix im Status.

5) Rollen und Verantwortlichkeiten in der Eskalation (kurz)

P1 (Primär): Triage, Playbook-Start, Kommunikation mit IC.
P2 (Sekundär): Backup, komplexe Aktionen, Kontext halten.
IC (Incident Commander): verkündet den SEV, entscheidet Freeze/Rollback, hält das Tempo.
Duty Manager: löst Blockaden, verteilt Ressourcen neu, trifft Org-Entscheidungen.
Comms: Status-Seite, Updates durch SLA.
Sicherheit IR: Isolierung, forensics, rechtliche Hinweise.
Vendor Owner: externe Anbieter, Switchover/Fallback.

6) Zeitgleiche (Landmarken)

SEV-1/0: ACK ≤ 5 м, Declare ≤ 10 м, First Comms ≤ 15 м, Updates q=15–30 м.
Klettergerüst: P1→P2 (5 m) → IC (10 m) → Duty Manager (15 m) → Exec on-call (30 m).
Sicherheit: keine Verzögerungen und „ruhige Stunden“, Updates q = 15m.

7) Routing und Segmentierung

Nach Dienst/Region/Tenant: Routing-Schlüssel = „Dienst + Region + Tenant“.
Das Quorum der Sonden: nur eskalieren, wenn die ≥2 unabhängiger Quellen bestätigt wird (synthetisch aus 2 Regionen + RUM/Business SLI).
Dedup: eine Master-Alert statt Dutzender Symptome (DB „rot“ jagt 5xx-Rauschen).

8) Ausnahmen und Sonderregelungen

Security/Legal: Eskalation von Security IR und Legal außer der Reihe; öffentliche Texte nur durch Abstimmung.
Anbieter: separate OLA/SLA-Matrix (Kontakte, Zeitzonen, Priorität).
Change Freeze: Wenn SEV-1/0, automatische Freeze-Releases und Configs.

9) Matrix-Reifegradmetriken

Ack p95 (SEV-1/0) ≤ 5 Min.
Zeit bis Declare (Median) ≤ 10 Min.
Comms SLA Adherence ≥ 95%.
Escalation Success (auf P1/P2 Ebene entschieden) ≥ 70%.
No-ACK escalations ↓ QoQ.
Vendor Response Time auf kritische Anbieter innerhalb des Vertrages.

10) Checklisten

Online (für On-Call)

• Der Impact auf SLO und das potenzielle SEV sind definiert.
• Erstellt von ACK und zugewiesen von IC (für SEV-1/0).
• Der Kriegsraum ist geöffnet, das Playbook ist angebracht.
• Status-Update veröffentlicht/geplant nach SLA.
• Freeze aktiviert (falls erforderlich), Provider/Sicherheit eskaliert.

Prozess (wöchentliche Überprüfung)

• Hat die Eskalationsleiter über SLA funktioniert?
• Gab es vor IC keine unnötigen Eskalationen?
• Sind die Benachrichtigungen der Kunden rechtzeitig und genau?
• Gab es Blocker (Zugriffe, Kontakte der Anbieter, „stummer“ Kanal)?
• CAPAs für Prozessfehler werden auch in Betrieb genommen.

11) Vorlagen

11. 1 Eskalationspolitik (YAML-Idee)

yaml policy:
sev_levels:
- id: SEV-0 declare_tgt_min: 5 first_comms_min: 10 update_cadence_min: 15
- id: SEV-1 declare_tgt_min: 10 first_comms_min: 15 update_cadence_min: 30 ack_sla_min:
default: 5 ladder:
- after_min: 5 escalate_to: "P2:oncall-<service>"
- after_min: 10 escalate_to: "IC:ic-of-the-day"
- after_min: 15 escalate_to: "DutyManager:duty"
- after_min: 30 escalate_to: "Exec:oncall-exec"
channels:
war_room: "#war-room-<service>"
alerts: "#alerts-<service>"
security: "#sec-war-room"
providers: "vendors@list"
quorum:
required_sources: 2 sources: ["synthetic:eu,us", "rum:<service>", "biz_sli:<kpi>"]
exceptions:
security: { quiet_hours: false, legal_approval_required: true }
providers: { auto_switch: true, notify_vendor_owner: true }

11. 2 „Time Escalation“ -Karte (für Bot)

T + 05m: no ACK → escalated to P2
T + 10m: no ACK/Declare → escalated to IC, war-room open
T + 15m: no Comms → reminder Comms, escalation Duty Manager
T + 30m: no Updates → IC reminder, Exec on-call CC

11. 3 Vorlage für das erste öffentliche Update

Impact: [services/regions] affected, [symptoms e.g. delays/errors].
Reason: Investigating; confirmed by monitoring quorum.
Actions: bypass routes/restrictions are enabled, provider switching is in progress.
Next update: [time, time zone].

12) Integration

Alert-as-Code: Jede Page-Regel verweist auf genau ein Playbook und kennt ihre eigene Eskalationsmatrix.
ChatOps: Befehle '/declare sev1', '/page p2', '/status update', Auto-Timer-Updates.
CMDB/Verzeichnis: Der Dienst hat Eigentümer, On-Call, Matrix, Anbieter, Kanäle.
Status-Seite: Vorlagen für SEV-1/0, Geschichte von Updates, Links zu RCA.

13) Anti-Muster

„Wir eskalieren alle auf einmal“ → Lärm und verschwommene Verantwortung.
Kein IC/Kriegsraum - Lösungen verbreiten sich über Chats.
Die Verzögerung des ersten Updates ist eine Zunahme von Beschwerden und PR-Risiken.
Keine Ausnahmen für die Sicherheit - rechtliche Risiken.
Externe Anbieter ohne Eigentümer und Kontakte.
Die Treppe ist nicht automatisiert - alles „an der Handbremse“.

14) Roadmap für die Umsetzung (3-5 Wochen)

1. Ned. 1: SEV-Kriterien und Timings erfassen; Zusammenstellen von Rollen-/Anbieterkontakten; Kanäle auswählen.
2. Ned. 2: Beschreiben Sie die Richtlinie (YAML), binden Sie sie an den Alert-as-Code, aktivieren Sie den Leiter im Pager/Bot.
3. Ned. 3: Pilot bei 2-3 kritischen Diensten; debuggen Comms SLAs und Vorlagen.
4. Ned. 4-5: Erweitern Sie die Abdeckung, führen Sie eine wöchentliche Escalation Review und Reifegradmetriken ein.

15) Das Ergebnis

Die Eskalationsmatrix ist die operative Verfassung der Vorfälle: Wer, wann und wie verbindet. Mit klaren SEVs, Timings, Kanälen, Ausnahmen für die Sicherheit und der Integration mit Playbooks und der Status-Seite reagiert das Team schnell, reibungslos und transparent, und die Nutzer sehen vorhersehbare Upgrades und eine sichere Wiederherstellung des Dienstes.