Vorfälle und SRE-Playbooks

1) Was ist ein Vorfall und wie korreliert er mit SLO?

Ein Vorfall ist ein Ereignis, das eine SLO/Service-Funktion verletzt oder das Risiko einer Verletzung verursacht (ein fehlerhaftes Budget wird inakzeptabel schnell durchgebrannt).
Klassische Metriken: MTTD, MTTA, MTTR, MTBF.
Budgetfehler und Burn-Rate definieren Priorität und Eskalationsfenster.

2) Schweregrade (SEV) und Kriterien

SEV-Trigger: 5xx% Überschreitung, p95> Schwelle, Payment decline spike, Kafka-lag> Schwelle, NodeNotReady> X min, TLS erlischt <7 Tage, DDoS-Signale/Leck.

3) Rollen und Verantwortung (RACI)

Incident Commander (IC) - alleinige Entscheidungsfindung, Verwaltung des Aufgabenflusses, Änderung des SEV-Status.
Ops Lead (Tech Lead) - technische Strategie, Hypothesen, Koordination von Fixes.
Communications Lead (Comms) - Status-Updates (intern/extern), StatusPage/Chat/Mail.
Scribe (Chronist) - Zeitlinien, Lösungen, Artefakte, Links zu Grafiken/Protokollen.
On-call Engineers/SMEs - Führen Sie Aktionen auf Playbooks.
Sicherheit/Datenschutz - aktiviert bei Sicherheitsvorfällen oder PII.
FinOps/Zahlungen - wenn Sie die Abrechnung/PSP/Kosten beeinflussen.

4) Lebenszyklus des Vorfalls

1. Detect (alert/report/synthetics) → Auto-Erstellung einer Incident Card.
2. Triage (IC zugewiesen, SEV zugewiesen, Mindestkontextsammlung).
3. Stabilisierung (Mitigation: Fichu/Rollback/Rate-Limit/Failover ausschalten).
4. Untersuchung (RCA-Hypothesen, Sammlung von Fakten).
5. Wiederherstellung des Dienstes (Validate SLO, Überwachung).
6. Kommunikation (intern/extern, Abschlussbericht).
7. Postmortem (keine Gebühren, CAPA-Plan, Eigentümer, Fristen).
8. Prävention (Tests/Alerts/Playbooks/Flags, Team-Nachschulung).

5) Kommunikation und „Kriegsraum“

Single Incident Channel ('# inc-sev1-YYYYMMDD-hhmm'), nur Fakten und Aktionen.
Befehle im Funkprotokoll-Stil: "IC: Ich weise Rollback Version 1 zu. 24 → ETA 10 min".
Status-Updates: SEV-1 alle 15 Minuten, SEV-2 alle 30-60 Minuten.
Status Page/externe Kommunikation - über Comms Lead per Template.
Verboten: parallele „ruhige“ Räume, ungeprüfte Hypothesen in einen gemeinsamen Kanal.

6) Alerting und SLO-burn (Regelbeispiel)

Schneller Kanal (1-5 min) und langsamer Kanal (1-2 h) Burn-Rate.
Multi-Signale: Budget-Fehler, 5xx%, p95, Kafka-lag, payment decline-rate, synthetics.
Die Suche nach der Ursache erfolgt erst nach Stabilisierung der Symptome.

promql
Ошибочная доля 5xx > SLO sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01

Burn-rate быстрый (пример)
(sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m])))
/ (1 - SLO) > 14.4

7) Playbooks vs Ranbooks

Playbook - ein Szenario von Aktionen nach Art des Vorfalls (Verzweigungen, Bedingungen, Risiken).
Ranbook ist eine spezifische „Karte“ von Schritten/Befehlen (Inspektionen, Fixes, Verifizierungen).
Regel: Das Playbook verweist auf mehrere Ranbooks (Rollbacks, Feature-Flags, Failover, Skalierung, Traffic-Blockierung etc.).

8) Vorlage der Incident Card

yaml id: INC-YYYYMMDD-XXXX title: "[SEV-1] Рост 5xx на API /payments"
status: active    monitoring    resolved sev: 1 reported_at: 2025-11-03T17:42Z ic: <ФИО>
ops_lead: <ФИО>
comms_lead: <ФИО>
scope: regions: [eu-west-1], tenants: [prod], services: [api, payments]
impact: "5xx=12% (обычно <0.5%), конверсия депозитов -20%"
mitigation: "откат на 1.23.4, включен rate-limit 2k rps, фича X выключена"
timeline:
- "17:42: алерт SLO burn-rate быстрый"
- "17:46: назначен IC, открыт war-room"
- "17:52: найден релиз 1.24 как кандидат"
- "18:02: откат завершен, 5xx вернулись к 0.3%"
artifacts:
dashboards: [...]
logs: [...]
traces: [...]
risk: "возможен очередной всплеск при включении фичи X"
next_steps: "канареечный релиз, тесты, постмортем до 2025-11-05"

9) SRE-Playbook-Vorlage (Markdown)

markdown
Плейбук: <название>
Область/симптомы
Список детекторов, сигнатуры в метриках/логах/трассах.

Быстрая стабилизация (Triage & Mitigation)
- [ ] Ограничить трафик/включить WAF-правило/фичефлаг OFF
- [ ] Роллбэк/канареечный релиз/выкатить фикс конфигурации
- [ ] Включить деградационный режим (read-only, кэш-форс)

Диагностика (RCA hints)
- Метрики: … Логи: … Трассы: …
- Частые первопричины/чек-лист гипотез

Риски и коммуникации
- Внутренние/внешние апдейты, SLA-обязательства

Верификация
- [ ] SLO восстановлено (порог/время окна)
- [ ] Нет регресса по смежным сервисам

Последующие действия
- CAPA, задачи в backlog, обновление алертов/дашбордов/плейбука

10) Typische Playbooks

10. 1 API 5xx Spike

Stabilisierung: Deaktivieren Sie den problematischen Ficheflag; API-Replikate verbessern Caching aktivieren; Release-Rollback.
Diagnose: Release-Diff, Logfehler (Top-Exceptions), p95-Wachstum, DB/Cache-Druck.
Risiken: Kaskade in Zahlungen/Backends.

10. 2 БД: replication lag / lock storm

Stabilisierung: Aussetzung schwerer Jobs/Berichte; Umleiten von Lesungen zum Assistenten; Erhöhung der wal_buffers/replika-sloty.
Diagnose: Lange Transaktionen, blockierende Anfragen, Planänderungen.
Fixierung: Indizes/Hints, Neuplanung von Jobs, Partitionierung von Anfragen.

10. 3 Kafka consumer lag

Stabilisierung: vorübergehend skalieren Verbraucher; Verringerung der Produktion von nicht kritischen Dienstleistungen; Erhöhung der Parteien/Quoten.
Diagnose: Rebalances, langsame Deserialisationen, GC-Pausen.
Verifikation: Lag → zum Zielwert, keine Drops.

10. 4 K8s NodeNotReady/Ressourcensturm

Stabilisierung: cordon + drain; Umverteilung der Lasten; CNI/Overlay prüfen; Schalten Sie die lauten DaemonSet's aus.
Diagnose: disk pressure, OOM, throttling, network drops.
Prävention: pod disruption budgets, resource limits/requests.

10. 5 TLS/Zertifikate verfallen

Stabilisierung: erzwungene Erneuerung des Geheimnisses/ingress; temporäre override.
Diagnose: Vertrauenskette, Clock-Skew.
Prävention: Alerta T-30/T-7/T-1, Auto-Regnum.

10. 6 DDoS/anormaler Datenverkehr

Stabilisierung: WAF/Bot-Regeln, Rate-Limit/Geo-Filter, Upstream-Shed-Last.
Diagnose: Angriffsprofile (L3/4/7), Quellen, „Regenschirme“.
Prävention: Anycast, Autoscaling, Caching, Play-Nice bei den Anbietern.

10. 7 Payment PSP Outage

Stabilisierung: Smart-Routing auf alternative PSP/Methoden; Retry mit Jitter anheben; „milder“ Abbau von UI.
Diagnose: Spike-Fehler durch Codes, API-Status/PSP-Status-Seiten.
Kommunikation: transparente Upgrades für Business und Sapport, korrekte ND/Conversion-Statistiken.

10. 8 Sicherheitsvorfall/PII-Leck

Stabilisierung: Knotenisolierung/Geheimrotation, Exfiltrationsblockierung, Legal Hold.
Diagnose: Zugriffszeitlinie, betroffene Probanden/Felder.
Hinweise: Aufsichtsbehörden/Partner/Nutzer auf Anforderungen der Gerichtsbarkeiten.
Prävention: Verstärkung der DLP/Segmentierung, „least privilege“.

11) Automatisierung von Playbooks

ChatOps-Befehle: '/ic set sev 1', '/deploy rollback api 1. 23. 4`, `/feature off X`.
Runbook-Bots: semi-automatische Schritte (Drain Node, Flip Traffic, Purge Cache).
Self-healing hooks: Detektor → standard mitigation (rate-limit, restart, scale).
Auto-Erstellung von Karten/Timeline aus Alerts und Teams.

12) Qualität der Playbooks: Checkliste

• Klare Symptome und Detektoren (Metriken/Protokolle/Tracks).
• Schnelle Stabilisierungsschritte mit Risikobewertung.
• Befehle/Skripte sind aktuell, in Staging geprüft.
• Überprüfung der SLO-Wiederherstellung.
• Kommunikationsmuster und Kriterien für externe Updates.
• Postmortem-Link und CAPA nach dem Schließen.

13) Postmortem (blameless) und CAPA

Das Ziel: lernen, nicht den Schuldigen finden.
Inhalt: was passiert ist, wie gefunden, was gut/schlecht war, Beitrag von Faktoren (die + Prozesse), Maßnahmen zu verhindern.
Laufzeit: SEV-1 - innerhalb von 48 Stunden; SEV-2 - 3 Arbeitstage.
CAPA: spezifische Eigentümer, Timing, messbare Effekte (MTTR-Reduktion/MTTD-Wachstum).

14) Rechtliche Aspekte und Beweisgrundlage

Legal Hold: Einfrieren von Logs/Tracks/Alert, Write-Once-Speicher.
Die Kette der Aufbewahrung der Artefakte: die Zugriffe nach den Rollen, die Kontrolle der Ganzheit.
Regulatorische Hinweise: Fristen/Vorlagen für Gerichtsbarkeiten (insbesondere bei betroffenen Zahlungen/PII).
Privacy: Minimierung und Maskierung von PII beim Parsen.

15) Incident Process Performance Metrics

MTTD/MTTA/MTTR nach Quartal und Domäne.
Korrekte SEV (Underrating/Overrating).
Anteil der Auto-Mitigate-Vorfälle.
Playbook-Abdeckung der Top-N-Szenarien (> 90%).
CAPA pünktlich durchführen.

16) Umsetzung nach Stufen

1. Woche 1: SEV-Matrix, On-Call-Rollen, allgemeines Kartenmuster, Kriegsraum-Reglement.
2. Woche 2: Playbooks für die Top 5 Symptome (5xx, DB-lag, Kafka-lag, NodeNotReady, TLS).
3. Woche 3: ChatOps/Bots, Auto-Generierung von Karten, Kommunikationsvorlagen/StatusPage.
4. Woche 4 +: Sicherheits-Playbooks, PSP-Outtakes, Legal Hold, regelmäßige Drill/Chaos-Spiele.

17) Beispiele für „schnelle“ Ranbooks (Fragmente)

Rollback API (K8s)

bash kubectl rollout undo deploy/api -n prod kubectl rollout status deploy/api -n prod --timeout=5m
Верификация:
kubectl -n prod top pods -l app=api

Drain node

bash kubectl cordon $NODE && kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --timeout=10m

Feature-flag OFF (Beispiel)

bash curl -X POST "$FF_URL/toggle" -H "Authorization: Bearer $TOKEN" -d '{"feature":"X","enabled":false}'

18) Mini-FAQ

Wann die SEV-1 heben?
Wenn eine wichtige SLO/Geschäftsfunktion (Zahlungen, Login, Spiel) leidet und die Burn-Rate das Budget für Stunden im Voraus „frisst“.

Was ist wichtiger - RCA oder Erholung?
Immer Stabilisierung, dann RCA. Die Zeit bis zur Stabilisierung ist der Hauptindikator.

Muss alles automatisiert werden?
Automatisieren Sie häufige und sichere Schritte; selten/riskant - durch Semi-Auto und IC-Bestätigung.

Ergebnis

Der robuste Incident-Prozess ruht auf drei Säulen: klare Rollen und SEV-Regeln, hochwertige Playbooks/Runbooks mit Automatisierung und eine Post-Mortems-Kultur ohne Vorwürfe. Pattern fixieren, On-Call trainieren, MTTR/fehlerhaftes Budget messen und Detektoren und Playbooks kontinuierlich verbessern - das reduziert direkt die Risiken und Kosten von Ausfallzeiten.