Operations-Playbooks

1) Was ist ein Playbook und wie unterscheidet es sich von einem Runbook?

Runbook ist eine lineare Schritt-für-Schritt-Anleitung für eine typische Operation/Alerta („mach eins, zwei, drei“).
Playbook - ein Entscheidungsbaum für Szenarien mit Gabeln: verschiedene Symptome → verschiedene Hypothesen → verschiedene Handlungszweige. Enthält Auswahlkriterien, Gate-Bedingungen und Fallback-Zweige.
Der Zweck des Playbooks besteht darin, die MTTA/MTTR und den Improvisationsgrad bei Unsicherheit zu reduzieren.

2) Wo Playbooks zuerst benötigt werden

Vorfälle: Rückgang der SLO (Availability/Latency/Success), Ausfall des Business SLI (Conversion/Payment Success).
Änderungen: Releases, Migrationen, Ficha-Flags, Configs (Canary/Rollback).
Wartungsfenster: DB/Broker-Upgrades, Zertifikatsrotationen.
Anbieter: PSP/KYC/CDN/IDP - Degradation und Swich-Over.
Sicherheit: kompromittierter Schlüssel, verdächtige Aktivität.
DataOps: überfällige Frische, Schaltungsdrift, Pipeline-Degradation.

3) Playbook-Standards (Mindestbesetzung)

1. Karte: ID, Version/Datum, Eigentümer (Team/Rolle), Dienste/Regionen/Tenanten, Verwandte Richtlinien/Standards.
2. Zweck und Auslösebedingungen: Welche SLOs/SLIs schützen, welche Alerts/Trigger gelten.
3. Symptome ↔ Hypothesen: Tabelle der Entsprechungen, wie man falsche Hypothesen schnell trimmt.
4. Entscheidungsbaum: Gabeln, Sicherheitstore, Stop/Continuation-Kriterien.
5. Aktionen: Schritt-für-Schritt-Blöcke mit Befehlen/Links zum Runbook 'und.
6. Kommunikation: Update-Vorlage (Impakt→Diagnostika→Deystviya→Sled. B. ein Update), Kanäle und Frequenzen.
7. Rollback/Folback: klarer Backout-Plan, Limits und UX Degradationsflag.
8. Abschlusskriterien: Metriken, Beobachtungszeitfenster.
9. Evidence: was zu speichern ist (Protokolle, Grafiken, Screenshots, Ticket-IDs).
10. Änderungshistorie: changelog, bekannte Einschränkungen.

4) Taxonomie der Playbooks (Beispielverzeichnis)

INC- - Incidents (SLO/SLI, Provider, Infrastruktur).
REL- - Releases, Rollbacks, Configs/Flags.
MW- - Wartungsfenster (DB/queue/cert/OS).
SEC- - Sicherheit (Zugriffe, Schlüssel, verdächtige Aktivitäten).
DATA- - Frische/Qualität/Schaltungen.
PROV- - externe Anbieter (PSP/KYC/CDN/Email/SMS).

5) Lebenszyklus und Besitz

1. Initiierung: basierend auf den Ergebnissen des Vorfalls/der Simulation/der Änderung.
2. Entwurf: Autor = Eigentümer des Dienstes; revue: SRE/Sicherheit/Daten (nach Domain).
3. Pilot: Tabletop/Spieltag; Erfassung von Laufzeiten und Defekten.
4. Veröffentlichung: in Repos (Docs-as-Code), Version, Tags, Links zu Dashboards.
5. Aktualisierung: gemäß RCA/CAPA, mindestens einmal pro Quartal; SLA Frische.
6. Archiv/Deprection: Bei Ersatz/Verlust der Relevanz.

6) Integration mit Werkzeugen

Alert → Playbook: Jede Page-Regel bezieht sich auf genau ein Basis-Playbook.
ChatOps: '/play start <id> 'öffnet die Karte, fixiert die Evidence, setzt die Update-Timer.
CMDB/Verzeichnis: Der Dienst hat eine Liste relevanter Playbooks, Besitzer, SLOs, Dashboards.
GitOps: Playbooks und Runbooks' und live in Git, PR-Reviews und Linters.

7) Qualitätsmetriken für Playbooks

Actionability: ≥ 90% der Starts führen zu konkreten Aktionen ohne Eskalation „unwissentlich“.
Time-to-first-action: ein oder zwei Minuten von Page bis zum ersten sinnvollen Schritt.
Coverage:% der Page-Alerts, denen ein Playbook zugeordnet ist (Ziel 100%).
Freshness: Der Anteil der Playbooks ist frischer als 90 Tage.
Defect rate: Bemerkungen zu Reviews/Simulationen auf 100 Playbooks.
Reuse: Wie oft das Playbook tatsächlich angewendet wurde (und zu welchen Ergebnissen es führte).

8) Anti-Muster

„Playbook-Enzyklopädie“ mit 20 Seiten ohne Entscheidungsbaum.
Befehle ohne Erwartungen an das Ergebnis („complete X“ - und was soll sich ändern?).
Kein Backout-Plan und keine Limits - das Risiko, dass das Problem eskaliert.
Keine spezifizierten Kommunikationskanäle/-intervalle - Anstieg der PR-Risiken.
Playbook ohne Besitzer/Aktualisierungsdatum - niemand glaubt an seine Relevanz.
Dutzende ähnlicher Playbooks statt eines parametrierbaren.

9) Mini-Playbook-Vorlage (YAML-Idee)

yaml id: INC-PAY-001 name: "Payment Success Down"
version: 2. 4 (2025-10-15)
owner: team-payments@sre scope: [prod, region: eu, tenants: all]
goal: "Restore success_ratio ≥ 98% without violating SLA"
triggers:
- alert: slo. burn. payment_success_ratio
- external_status: psp-a partial outage symptoms:
- "5xx growth in payments-api"
- "p95 latency> 400ms on PSP-A"
decision_tree:
- if: "quorum(eu,us) confirms drop AND PSP-A status=partial"
then:
- action: "Reduce PSP-A weight to 30%"
runbook: rb://payments/traffic-shift guardrails: ["success_ratio improving 10m", "p95<300ms"]
- action: "Enable degrade_payments_ux"
runbook: rb://payments/feature-flags
- action: "Status update (30m) by template"
comms: statuspage://payments else:
- action: "Check database/cache/queue"
runbook: rb://payments/diag-stack fallback:
- action: "Failover на PSP-B 70%"
guardrails: ["fraud_rate stable", "chargeback risk noted"]
rollback:
- condition: "PSP-A green 60m"
- steps:
- "Weight of PSP-A 30→70→80 (every 30 m at green SLI)"
evidence:
- "SLI screenshots, p95/5xx graphs, links to logs/trails"
completion:
- "success_ratio ≥98% during 30 m, no burn in 6 h"

10) Fertige Beispiele (Fragmente)

A) Zahlungen: „Anbieter degradiert in einer Region“

Symptome: Abnahme der success_ratio der TR-Kohorte, Anstieg der PSP-A-Timeouts.
Lösungen: Reduzieren Sie das Gewicht von PSP-A für TR, aktivieren Sie degrade-UX, stärken Sie Retrays mit Budget ≤ SLA, bereiten Sie ein Client-Upgrade vor.
Backout: Gewichte mit einem grünen SLI von 60 Minuten zurückgeben.

B) DB: „Wachstum p99 und Verbindungsfehler“

Symptome: p99↑, connection reset bugs, wait events growth.
Lösungen: Aktivieren Sie Read-Only-Skripte, begrenzen Sie die Write-Last, skalieren Sie den Pool/Replikate, falls erforderlich, einen Hot-Flaver.
Backout: Rollback der Parameter, Replikat-Prime.

C) Cache: „Miss Rate ↑ → Belastung der DB“

Symptome: Fräulein Rate> 40%, CPU DB Wachstum.
Lösungen: eviction policy ausgleichen, Speicher/Sharding erhöhen, Read-Through vorübergehend aktivieren, RPS auf Hot Keys begrenzen.
Backout: Geben Sie die Richtlinie zurück, erstellen Sie den problematischen Shard neu.

D) CDN: „Regionale Degradierung von Inhalten“

Symptome: Anstieg der Latenz/Timeout in einem Land, RUM Beschwerden.
Lösungen: Routing Map/GSLB ändern, problematischen POP umgehen, TTL reduzieren, Origin-Shield aktivieren.
Comms: Status-Updates mit Geographie des Einflusses.

E) KYC: „Identitätsversagen“

Symptome: Abnahme der Approve-Rate, Wachstum der vendor_error.
Die Lösungen: einen Teil des Verkehrs auf einen alternativen Anbieter umstellen, die Strenge der Regeln (im Rahmen der Politik) reduzieren, eine manuelle Überprüfung für VIPs einleiten.
Compliance: Protokollierung aller Änderungen, ggf. Risk/Legal-Mitteilungen.

11) Kommunikation (Update-Vorlage)

Impact: EU payment success drop (-3. 1% to SLO, 25 min).
Diagnosis: confirmed by quorum; PSP-A partial outage; p95 = 420ms.
Action: PSP-A weight reduced to 30%, degrade-UX included; next update 18:30 UTC.

12) Checkliste des Playbook-Autors

• Ziel, Besitzer, SLO/SLI und Trigger angegeben.
• Es gibt eine Tabelle „Symptome ↔ Hypothesen“ und einen Entscheidungsbaum.
• Machbare Schritte mit erwarteten Ergebnissen und Sicherheitsgates.
• Backout/Fallback und Rückgabebedingungen sind vorgeschrieben.
• Kommunikationsmuster und Häufigkeit der Aktualisierungen.
• Links zu Dashboards/Alerts/Log-Suchen/Traces.
• Obligatorischer Abschnitt evidence und Abschlusskriterien.
• Version, Datum, Frische SLA, Änderungshistorie.

13) Reviewer Checkliste

• Das Playbook ist am Tabletop/Spieltag spielbar.
• Die Schritte sind sicher (Limits/Kanarienvogel/Auto-Rollback), Geheimnisse werden nicht preisgegeben.
• Die Rollen und Eskalationen sind klar; IC/Comms sind angegeben.
• Keine Duplizierung mit benachbarten Playbooks; Parameter übergeben.
• Es ist klar, wann zu stoppen und gehen Sie zu Fallback/Rollback.
• Das Dokument ist mit einem 1-Klick-Alert verfügbar.

14) Parametrierung und Wiederverwendung

Geben Sie die Variablen (Region, Anbieter, Schwellenwerte) in 'Werte' ein.
Allgemeine Schritte (z.B. „Anbietergewicht reduzieren“, „degrade-UX ermöglichen“) mit separaten Runbooks gestalten.
Unterstützen Sie die Generatoren aus den Vorlagen: 'plb new --type = INC --service = payments'.

15) Umsetzungsfahrplan (4-6 Wochen)

1. Ein Page-Alert-Inventar → jedem ein Basis-Playbook zuordnen.
2. Vorlagen: YAML/Markdown Struktur, Checklisten und Linter genehmigen.
3. Die Top-5-Szenarien (Zahlungen/DB/CDN/KYC/Cache) → auf Tabletop geschrieben/zurückgesetzt werden.
4. Integration: Links von alert, ChatOps-Team, evidence-bot.
5. Übungen: wöchentliche Mini-Drill für ein Playbook; AAR→uluchsheniya.
6. SLA Frische und vierteljährliche Revue; Qualitätsmetrikbericht.

16) Das Ergebnis

Playbooks sind Betriebsszenarien mit Gabelungen und Geländern, die das Chaos „und was tun?!“ in eine vorhersehbare Abfolge von Entscheidungen übersetzen. Wenn Playbooks standardisiert, in Alerts integriert und regelmäßig trainiert werden, reagiert das Team schneller, die Risiken werden kontrolliert und das Geschäft sieht Stabilität und Einsatzreife.