Run SheetDevOpsResilience Testing

Game Day

KomplexitätHigh

ZeitHalber Tag

Teilnehmende5-20

FormatWorkshop

MaturityEstablished

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenRunbook

Mindestens ein Runbook fuer den geplanten Failure-Modus existiert, sodass Game Day die Anweisungen testen kann.

Ohne: Ohne Runbook wird der Game Day Improvisation statt Validierung, Lernrate ueber Prozesse bleibt niedrig.

Vorher abschließenIncident Command

Incident-Rollen (Commander, Communicator, Operator) sind etabliert, sodass die Uebung realistisch ablaeuft.

Ohne: Ohne Rollen wird Game Day zur Diskussionsrunde, Reaktionszeit und Eskalation nicht gemessen.

Vorbereitung

Was vor Start vorliegen muss

Materialien

Failure-Injection-Tools (Chaos Mesh, Gremlin, AWS Fault Injection Simulator); Beobachtungsstack (Datadog, Grafana, Logs); Communication-Channel; Drehbuch mit Szenarien und Erwartungen; Sicherheitsabschaltung.

Personen / Rollen

Ein Game Day Master (Drehbuch-Autor); Incident Commander; Operator-Team; Observer pro relevantem Service; Stakeholder-Vertreter; Safety Officer mit Abbruch-Autoritaet.

Vorabinfos

Architektur-Diagramm; SLO/SLA der betroffenen Services; bekannte Schwachstellen aus vergangenen Incidents; aktuelle Runbooks; Pre-Test-Health-Check.

Zeitbedarf

4-8 h fuer einen Game Day, plus 1-2 Wochen Vorbereitung

Setup

Termin im Kalender, alle relevanten Stakeholder informiert. Production-Variante: Failure auf Staging oder isoliertem Tenant. Sicherheits-Abbruch (Big Red Button) definiert. Comms-Plan, damit echte Nutzer nicht verunsichert werden.

Kernfrage

Die eine Frage, die diese Methode beantwortet

Wie reagieren System, Tools und Team auf realistisch injizierte Fehler, und welche Luecken in Runbooks, Monitoring oder Rollen werden sichtbar?

Ablauf

Marker: Phase

Schritt	Dauer	Aktion	Hinweis
1Phase 1: Drehbuch und Hypothesen	3-5 Tage Vorlauf	Drei bis fuenf Szenarien definieren (z. B. DB-Failover, Pod-Crash, Region-Outage). Pro Szenario Hypothese, was erwartet wird, und Erfolgskriterien (z. B. Recovery in 5 min).	Hypothese explizit aufschreiben. Wenn niemand vorher sagt, was er erwartet, kann auch keine Ueberraschung gelernt werden.
2Phase 2: Setup und Sicherheits-Brief	30 min	Beobachtungsstack verifizieren. Rollen verteilen. Big-Red-Button-Bedingungen klaeren (z. B. echter Kunden-Impact ueber Schwelle X). Comms an Stakeholder.	Wenn Stakeholder nicht informiert sind, kann ein echter Alarm Eskalationen ausloesen, die nicht zur Uebung gehoeren. Klare Kennzeichnung pflicht.
3Phase 3: Injection und Reaktion	2-4 h	Szenario nach Szenario: Fehler injizieren, Team reagiert mit Runbook, Observer protokollieren Reaktionszeiten, Entscheidungen, Tool-Verhalten. Game Day Master verzoegert ggf. Aufloesung.	Realismus halten. Wenn das Team weiss, dass es eine Uebung ist, sinkt Adrenalin. Trotzdem keine zu langen Verzoegerungen, sonst Frust.
4Phase 4: Recovery und Verifikation	30-60 min	Nach jedem Szenario kontrollierte Recovery durch das Team. Beobachter pruefen, ob Monitoring den Fehler erkannt und das Runbook funktioniert hat.	Recovery ist Teil der Uebung. Wer in der Recovery scheitert, hat ein Runbook-Problem. Bei vollstaendigem Stillstand Safety Officer aktiviert Big Red Button.
5Phase 5: Debrief und Followups	60-90 min	After-Action Review pro Szenario: Plan vs. Realitaet, Ursachen, Lessons, Massnahmen. Top-3-Lessons in Tickets mit Owner und Frist. Runbook-Updates planen.	Lessons ohne Followup ist verschwendeter Game Day. Maximal drei Massnahmen pro Game Day, sonst geht es im Tagesgeschaeft unter.

Artefakt

Was am Ende rauskommt

Form

Game-Day-Report mit Szenarien, Hypothesen, Reaktionsmetriken (Time-to-Detect, Time-to-Mitigate), Beobachtungen, Lessons Learned und Massnahmenliste mit Owner und Frist.

Tool-Alternativen

Gremlin oder Chaos Mesh fuer Failure Injection
AWS Fault Injection Simulator, Azure Chaos Studio
Custom Skripte mit Toxiproxy oder iptables
Confluence- oder Notion-Report mit Anhaengen (Logs, Screenshots)
PagerDuty Drill Mode fuer realistische Alarmierung

Versionierung / Ownership

Pro Game Day ein Eintrag mit Datum, Szenarien und Ergebnissen. Vergleich ueber Game Days hinweg (Trend Time-to-Detect, Time-to-Mitigate). Runbook-Versionen vor und nach dem Game Day verlinken.

markdown

Game Day Arbeitsvorlage

Kompakte Arbeitsvorlage für Game Day mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

# Game Day Arbeitsvorlage

## Ziel

Realistische Übung, um Incident Response und Recovery zu proben.

## Kontext

Wann und wofür nutzen wir diese Methode?

## Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

## Durchführung

Kurze Notizen entlang des Run Sheets.

## Ergebnisartefakte
- Simulation Notes:
- Gaps List:
- Updated Runbooks:

## Annahmen und offene Fragen

- ...

## Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Beispielausgabe

Konkret gefülltes Szenario

game-day-beispiel.md

markdown

## Game Day - Plattform-Team Workspot, 15.05.2026

**Beteiligte**: Game Day Master @lisa, Incident Commander @ben, Operator (3 Engineers), Observer (2 SRE), Safety Officer @marcus.

**Szenarien**
1. DB-Primary-Failover.
2. CDN-Region-Outage (eu-central).
3. Auth-Service 100% 5xx fuer 10 min.

**Hypothesen**
- Sz 1: Recovery in <3 min via Auto-Failover.
- Sz 2: Failover auf eu-west via DNS in <5 min.
- Sz 3: Runbook RB-AUTH-01 fuehrt zur Mitigation in <10 min.

**Ergebnisse**
| Szenario | Time-to-Detect | Time-to-Mitigate | Hypothese erfuellt |
|---|---|---|---|
| 1 DB-Failover | 0:42 | 2:18 | Ja |
| 2 CDN-Outage | 1:54 | 14:30 | Nein (DNS-TTL 300s, manuelle Switch noetig) |
| 3 Auth 5xx | 0:28 | 4:50 | Ja, Runbook funktionierte |

**Top-Lessons**
- CDN-DNS-TTL ist 300s und blockiert Failover. Senkung auf 60s noetig.
- Auth-Runbook funktionierte einwandfrei, Cycle Time im Limit.
- Observer-Tool meldete CDN-Outage erst nach 1:54 (Polling-Intervall 60s).

**Massnahmen**
- GD-01: CDN-DNS-TTL auf 60s reduzieren. Owner: @marcus, bis 22.05.
- GD-02: CDN-Health-Check-Polling auf 15s. Owner: @lisa, bis 29.05.
- GD-03: Drill 2x pro Quartal als Standard etablieren. Owner: @ben.

Was tun

Mindestens ein Observer pro Szenario, mit Stoppuhr und Notizvorlage. Reaktionsmetriken sind harte Fakten, nicht Anekdoten.

Abbruchkriterien

Done-Signale, in unter einer Minute prüfbar

Keine Failure-Injection-Werkzeuge verfuegbar, Szenarien nicht realistisch ausloesbar.

Safety Officer und Big Red Button nicht etabliert, Risiko fuer echte Nutzer.

Incident-Rollen nicht klar besetzt, Reaktion bleibt Improvisation.

Runbooks fuer geplante Szenarien existieren nicht, Hypothesen nicht pruefbar.

Stakeholder-Kommunikation nicht geklaert, Eskalations-Risiko nicht kalkuliert.

Service hat aktuell aktive Probleme, zusaetzlicher Stress unverantwortlich.

Run Sheet durchgearbeitet?

Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.

Zum Steckbrief Weitere Methoden