MethodenanleitungDevOps

Game Day

Die Anleitung zur Methode: Voraussetzungen und Materialien klären, den gesamten Ablauf verstehen und Ergebnisse, Stolperfallen sowie Abbruchkriterien nachschlagen.

KomplexitätHoch

ZeitHalber Tag

Teilnehmende5-20

FormatWorkshop

ReifegradEstablished

Planung vorbereiten

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenKlare Abgrenzung

Wiederkehrendes Übungsprogramm mit genehmigtem Szenario, Sicherheitsgrenzen und betroffenen Betriebsrollen.

Ohne Grenze werden Daten, Perspektiven oder Abläufe vermischt.

Vorher abschließenZugang zu Belegen

Relevante Personen und Quellen können einbezogen werden.

Lücken bleiben sichtbar; fehlende Evidenz darf nicht erfunden werden.

Vorbereitung

Was vor Start vorliegen muss

Materialien

Gemeinsame Arbeitsfläche, zugängliche Quellen und Notiz für Entscheidungen.

Personen / Rollen

Übungsleitung · Safety Lead · Einsatzteam · Beobachtende

Vorabinfos

Frage, Zeitraum, Datenzugriff, beteiligte Rollen und bekannte Unsicherheiten vorab klären.

Zeitbedarf

Wiederkehrende Übung; Vorbereitung, Durchführung, Recovery und Maßnahmenreview getrennt planen.

Setup

Eine gemeinsame Version anlegen. Fakten, Annahmen und Entscheidung getrennt kennzeichnen.

Kernfrage

Die eine Frage, die diese Methode beantwortet

Erkennen und bewältigen System und Einsatzteam dieses vorab begrenzte Störungsszenario sicher?

Ablauf

Phasen mit Ziel, Durchführung, Ergebnis und Stolperfalle

Game Day prüft Resilienz, Betriebsverfahren und Teamkoordination durch kontrollierte Störungsübungen. Die Beobachtungen zeigen, welche Schutzmaßnahmen und Abläufe sich bewähren und wo weitere Verbesserungen nötig sind.

Sicherheitsbegrenztes Szenario und Übungserkenntnis

Fiktives Lehrbeispiel

Übe regelmäßig kontrollierte Störungsszenarien, um Resilienz, Verfahren und Teamkoordination zu überprüfen.

Szenario

Formuliere Lernziel, Dienst, Szenario und Umgebung.

Read-only-Abhängigkeit in isolierter Testumgebung abschalten.

Sicherheitsgrenze

Definiere Beteiligte, Beobachtung, Kill-Switch und Grenzwerte.

Kein Produktions-Traffic; Safety Lead mit sofortigem Kill-Switch.

Erwartete Signale

Erfasse Alarme, Systemzustand und Reaktion während der Übung.

Alarm binnen 2 min; Fallback aktiv; keine Datenänderung; Nutzerwirkung <5 min.

Lernpunkt

Notiere Wiederherstellung, Befunde, Owner und nächste Übung.

Fiktiver Befund: Dashboard zeigt Abhängigkeit nicht. Owner ergänzt Anzeige; Re-Test im nächsten Quartal.

Fiktive Übung: In einer produktionsnahen Testumgebung fällt eine Read-only-Abhängigkeit aus. Ziel: Alarm erkennen, Fallback aktivieren und Kundenauswirkung unter 5 Minuten halten. Safety Lead kann jederzeit abbrechen. Übung deckt fehlenden Alarm im Dashboard auf; kein produktiver Traffic wird injiziert.

Conduct game days regularly · AWS Well-Architected

1
Übungsziel
Übungsziel und Risiko wählen
Ziel
Ist das Szenario genehmigt und begrenzt?
Voraussetzungen für diesen Schritt
- Resilienzziel, Dienstkritikalität und Risiko
Durchführung
- Wähle kritischen Dienst und Lernziel; prüfe Blast Radius und sichere Umgebung.
- Ist das Szenario genehmigt und begrenzt?
Ergebnis
Begrenztes, genehmigtes Störungsszenario
Begrenztes, genehmigtes Störungsszenario
Qualitätscheck
Ist das Szenario genehmigt und begrenzt?
Stolperfalle
Fehler injiziert außerhalb sicherer Grenze Blast Radius und Kill-Switch vor Beginn testen; Safety Lead stoppt bei Schwelle.
Zeitlicher Rahmen: Teil des vereinbarten Arbeitsblocks; Recherche ggf. separat.
2
Grenzen
Teilnehmende und Stopps festlegen
Ziel
Kann jede Person die Übung stoppen?
Voraussetzungen für diesen Schritt
- Genehmigtes Szenario, Teilnehmer und Kill-Switch
Durchführung
- Informiere Rollen, Beobachtende und Stakeholder; definiere Kill-Switch und Erfolgssignale.
- Kann jede Person die Übung stoppen?
Ergebnis
Teilnehmer-, Kommunikations- und Safety-Plan
Teilnehmer-, Kommunikations- und Safety-Plan
Qualitätscheck
Kann jede Person die Übung stoppen?
Stolperfalle
Übung überrascht betroffene Stakeholder Szenario, Zeitpunkt und mögliche Auswirkungen vorab mitteilen.
Zeitlicher Rahmen: Teil des vereinbarten Arbeitsblocks; Recherche ggf. separat.
3
Durchführung
Szenario kontrolliert ausführen
Ziel
Bleibt der reale Nutzerschutz gewährleistet?
Voraussetzungen für diesen Schritt
- Monitoring, Beobachterprotokoll und reale Impact-Grenze
Durchführung
- Führe Fehler gemäß Plan aus, beobachte System und Reaktion; stoppe bei Grenzwertverletzung.
- Bleibt der reale Nutzerschutz gewährleistet?
Ergebnis
Beobachtete System- und Teamreaktion
Beobachtete System- und Teamreaktion
Qualitätscheck
Bleibt der reale Nutzerschutz gewährleistet?
Stolperfalle
Nur Technik wird geübt Betriebs-, Kommunikations- und Entscheidungsrollen einbeziehen.
Zeitlicher Rahmen: Teil des vereinbarten Arbeitsblocks; Recherche ggf. separat.
4
Lernen
Erkenntnisse nachverfolgen
Ziel
Fließen Lücken in Verfahren und Folgetest ein?
Voraussetzungen für diesen Schritt
- Befunde, Abhilfen und nächster Übungstermin
Durchführung
- Stelle Normalbetrieb her; sichere Beobachtungen, Maßnahmen, Owner und nächsten Übungstermin.
- Fließen Lücken in Verfahren und Folgetest ein?
Ergebnis
Nachverfolgte Befunde samt Wiederholungsplan
Nachverfolgte Befunde samt Wiederholungsplan
Qualitätscheck
Fließen Lücken in Verfahren und Folgetest ein?
Stolperfalle
Erkenntnisse werden nicht zurückgeführt Maßnahmen in Runbooks, Alarmierung und nächstes Szenario übernehmen.
Zeitlicher Rahmen: Teil des vereinbarten Arbeitsblocks; Recherche ggf. separat.

Artefakt

Was am Ende rauskommt

Skizze: so sieht das Artefakt aus

Game Day · kontrollierter Resilience-TestGeplante Störungen einspielen, Teamreaktion beobachten, Runbooks prüfen und Lernen ableiten

Form

Versioniertes Ergebnis mit Frage, Evidenz, offenen Punkten, nächster Maßnahme, Verantwortung und Reviewtermin.

Versionierung / Ownership

Datum, Geltungsbereich, Quellen und Änderungen festhalten. Frühere Beobachtungen erhalten.

Tool-Alternativen

Whiteboard oder Papier
Gemeinsame Tabelle
Projektablage mit Versionshistorie

game-day-working-template.md

Bereite Game Day mit klarer Frage, Rollen und Quellen vor.

Game Day: Arbeitsvorlage

Fragestellung

Noch zu klären

Gewünschtes Ergebnis

Noch zu klären

Rahmen

Vollständigen Ablauf planen Zeit: Nach Umfang und verfügbaren Belegen festlegen

Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.

Vorbereitung für diesen Umfang

Methodische Grundausstattung

Materialien: Gemeinsame Arbeitsfläche, zugängliche Quellen und Notiz für Entscheidungen.
Rollen: Übungsleitung · Safety Lead · Einsatzteam · Beobachtende
Vorab-Infos: Frage, Zeitraum, Datenzugriff, beteiligte Rollen und bekannte Unsicherheiten vorab klären.
Gesamter Zeitbedarf: Wiederkehrende Übung; Vorbereitung, Durchführung, Recovery und Maßnahmenreview getrennt planen.
Setup: Eine gemeinsame Version anlegen. Fakten, Annahmen und Entscheidung getrennt kennzeichnen.

Für die Arbeitsschritte bereitstellen

Übungsziel: Übungsziel und Risiko wählen

Resilienzziel, Dienstkritikalität und Risiko

Grenzen: Teilnehmende und Stopps festlegen

Genehmigtes Szenario, Teilnehmer und Kill-Switch

Durchführung: Szenario kontrolliert ausführen

Monitoring, Beobachterprotokoll und reale Impact-Grenze

Lernen: Erkenntnisse nachverfolgen

Befunde, Abhilfen und nächster Übungstermin

Sicherheitsbegrenztes Szenario und Übungserkenntnis

Szenario

Formuliere Lernziel, Dienst, Szenario und Umgebung.

...

Sicherheitsgrenze

Definiere Beteiligte, Beobachtung, Kill-Switch und Grenzwerte.

...

Erwartete Signale

Erfasse Alarme, Systemzustand und Reaktion während der Übung.

...

Lernpunkt

Notiere Wiederherstellung, Befunde, Owner und nächste Übung.

...

Leere Vorlage: beginne mit einer abgegrenzten Frage. Trage nur erhobene Fakten ein, markiere Annahmen und halte offene Fragen sowie Quellen fest.

Conduct game days regularly · AWS Well-Architected

Übungsziel: Übungsziel und Risiko wählen

Erwartetes Artefakt: Begrenztes, genehmigtes Störungsszenario

Begrenztes, genehmigtes Störungsszenario

Eintrag:

...

Ist das Szenario genehmigt und begrenzt?

Grenzen: Teilnehmende und Stopps festlegen

Erwartetes Artefakt: Teilnehmer-, Kommunikations- und Safety-Plan

Teilnehmer-, Kommunikations- und Safety-Plan

Eintrag:

...

Kann jede Person die Übung stoppen?

Durchführung: Szenario kontrolliert ausführen

Erwartetes Artefakt: Beobachtete System- und Teamreaktion

Beobachtete System- und Teamreaktion

Eintrag:

...

Bleibt der reale Nutzerschutz gewährleistet?

Lernen: Erkenntnisse nachverfolgen

Erwartetes Artefakt: Nachverfolgte Befunde samt Wiederholungsplan

Nachverfolgte Befunde samt Wiederholungsplan

Eintrag:

...

Fließen Lücken in Verfahren und Folgetest ein?

Offene Fragen und nächste Schritte

...

Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/game-day/run-sheet

Beispielausgabe

Konkret gefülltes Szenario, fiktives Beispiel

Fiktives Beispiel zur Orientierung. Die genannten Mengen und Zeiten beschreiben diesen Fall und sind keine allgemeine Vorgabe.

game-day-beispiel.md

Konkret gefülltes Szenario, fiktives Beispiel

Fiktives Lehrbeispiel

Alle Namen und Werte sind erfunden und dienen nur der Illustration. Offene Erklärungen bleiben als Fragen markiert.

Stolperfallen

Symptome erkennen, gegensteuern

Kurzüberblick, vollständiger Text steht in der jeweiligen Phase im Ablauf

Übungsziel und Risiko wählenFehler injiziert außerhalb sicherer GrenzeIn der Phase ansehen
Teilnehmende und Stopps festlegenÜbung überrascht betroffene StakeholderIn der Phase ansehen
Szenario kontrolliert ausführenNur Technik wird geübtIn der Phase ansehen
Erkenntnisse nachverfolgenErkenntnisse werden nicht zurückgeführtIn der Phase ansehen