Session Brief: Game Day

Ziel

Artefakt: Simulation Notes

Arbeitsfrage

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

Kontext

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

Setup

• Format: Methoden-Session
• Dauer: 4-8 h fuer einen Game Day, plus 1-2 Wochen Vorbereitung
• Modus: Workshop
• Teilnehmende: Ein Game Day Master (Drehbuch-Autor); Incident Commander; Operator-Team; Observer pro relevantem Service; Stakeholder-Vertreter; Safety Officer mit Abbruch-Autoritaet.
• Owner: Ein Game Day Master (Drehbuch-Autor)
• Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
• Ergebnislogik: Artefakt fertigstellen

Beteiligungslogik

Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

Ergebnislogik

Die Session arbeitet direkt auf Simulation Notes hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

Input

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

Vorbereitung

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.

Agenda

1. Phase 1: Drehbuch und Hypothesen (3-5 Tage Vorlauf) Owner: Facilitator Aktion: 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). Hinweis: Hypothese explizit aufschreiben. Wenn niemand vorher sagt, was er erwartet, kann auch keine Ueberraschung gelernt werden. Output: Simulation Notes

2. Phase 2: Setup und Sicherheits-Brief (30 min) Owner: Facilitator Aktion: Beobachtungsstack verifizieren. Rollen verteilen. Big-Red-Button-Bedingungen klaeren (z. B. echter Kunden-Impact ueber Schwelle X). Comms an Stakeholder. Hinweis: Wenn Stakeholder nicht informiert sind, kann ein echter Alarm Eskalationen ausloesen, die nicht zur Uebung gehoeren. Klare Kennzeichnung pflicht. Output: Gaps List

3. Phase 3: Injection und Reaktion (2-4 h) Owner: Facilitator Aktion: Szenario nach Szenario: Fehler injizieren, Team reagiert mit Runbook, Observer protokollieren Reaktionszeiten, Entscheidungen, Tool-Verhalten. Game Day Master verzoegert ggf. Aufloesung. Hinweis: Realismus halten. Wenn das Team weiss, dass es eine Uebung ist, sinkt Adrenalin. Trotzdem keine zu langen Verzoegerungen, sonst Frust. Output: Updated Runbooks

4. Phase 4: Recovery und Verifikation (30-60 min) Owner: Facilitator Aktion: Nach jedem Szenario kontrollierte Recovery durch das Team. Beobachter pruefen, ob Monitoring den Fehler erkannt und das Runbook funktioniert hat. Hinweis: Recovery ist Teil der Uebung. Wer in der Recovery scheitert, hat ein Runbook-Problem. Bei vollstaendigem Stillstand Safety Officer aktiviert Big Red Button. Output: Simulation Notes

5. Phase 5: Debrief und Followups (60-90 min) Owner: Owner Aktion: After-Action Review pro Szenario: Plan vs. Realitaet, Ursachen, Lessons, Massnahmen. Top-3-Lessons in Tickets mit Owner und Frist. Runbook-Updates planen. Hinweis: Lessons ohne Followup ist verschwendeter Game Day. Maximal drei Massnahmen pro Game Day, sonst geht es im Tagesgeschaeft unter. Output: Gaps List

6. Artefakt veröffentlichen (10 min) Owner: Owner Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen. Output: Simulation Notes

Abschluss

• Ergebnisartefakt aktualisieren: Simulation Notes
• Ablageort, Version und Review-Empfänger festlegen.
• Owner, nächster Schritt und Reviewtermin festlegen.

Simulation Notes: Game Day

Arbeitsfrage

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

Kontext

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

Beteiligte

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

Input

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

Vorlage

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 Runsheets.

Ergebnisartefakte

• Simulation Notes:
• Gaps List:
• Updated Runbooks:

Annahmen und offene Fragen

• ...

Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Fertigstellungscheck

• Simulation Notes ist vollständig genug für Review:
• Ablageort:
• Version / Status:
• Review durch:
• Nächster Schritt:

Nächster Schritt

• Ergebnis prüfen
• offene Fragen markieren
• Review oder Entscheidung terminieren