Meine Session planen

# 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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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 Run Sheets.

## 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