methodatlas
Method guideDevOps

Game Day

A practical method guide: clarify prerequisites and materials, understand the complete process, and look up outputs, pitfalls, and stop criteria.

ComplexityHigh
TimeHalber Tag
Participants5-20
FormatWorkshop
MaturityEstablished
Prepare plan
01

Prerequisite

What needs to be finished first

Complete firstClear scope

A recurring exercise program with an approved scenario, safety boundaries, and relevant operations roles.

Without a boundary, data, perspectives, or flows become mixed.
Complete firstAccess to evidence

Relevant people and sources can be included.

Gaps remain visible; missing evidence must not be invented.
02

Preparation

What needs to be ready before start

Materials

Shared workspace, accessible sources, and a decision log.

People / roles

Exercise lead · safety lead · response team · observers

Pre-read

Clarify the question, timeframe, data access, roles, and known uncertainties in advance.

Time needed

Recurring exercise; plan preparation, execution, recovery, and action review separately.

Setup

Create a shared version. Label facts, assumptions, and decisions separately.

03

Core question

The one question this method answers

Can the system and response team safely detect and handle this bounded failure scenario?

04

Flow

Phases with goal, actions, output and pitfall

Game Day examines resilience, operational procedures, and team coordination through controlled failure exercises. Observations show which safeguards and procedures work and where further improvements are needed.

Safety-bounded scenario and exercise learning

Fictional worked example

Regularly rehearse controlled failure scenarios to check resilience, procedures, and team coordination.

Scenario

State learning goal, service, scenario, and environment.

Disable a read-only dependency in an isolated test environment.

Safety boundary

Define participants, observation, kill switch, and thresholds.

No production traffic; safety lead holds immediate kill switch.

Expected signals

Capture alerts, system state, and response during exercise.

Alert within 2 min; fallback active; no data changes; user impact <5 min.

Learning

Record recovery, findings, owners, and next exercise.

Fictional finding: dashboard omits dependency. Owner adds visibility; retest next quarter.

Fictional exercise: a read-only dependency fails in a production-like test environment. Goal: detect alert, activate fallback, keep user impact under 5 minutes. Safety lead can stop at any time. Exercise reveals a missing dashboard alert; no production traffic is injected.

Conduct game days regularly · AWS Well-Architected

  1. 1

    Objective

    Choose objective and risk

    Goal

    Is the scenario approved and bounded?

    Inputs for this step

    • Resilience goal, service criticality, and risk

    Actions

    • Choose a critical service and learning goal; check blast radius and safe environment.
    • Is the scenario approved and bounded?

    Output

    Bounded, approved failure scenario

    Bounded, approved failure scenario

    Quality check

    Is the scenario approved and bounded?

    Pitfall

    Fault injected beyond safe boundary Test blast radius and kill switch; safety lead stops at threshold.

    Timing: Part of the agreed work block; research may be separate.

  2. 2

    Boundaries

    Prepare participants and stop controls

    Goal

    Can anyone stop the exercise?

    Inputs for this step

    • Approved scenario, participants, and kill switch

    Actions

    • Inform responders, observers, and stakeholders; define kill switch and success signals.
    • Can anyone stop the exercise?

    Output

    Participant, communications, and safety plan

    Participant, communications, and safety plan

    Quality check

    Can anyone stop the exercise?

    Pitfall

    Exercise surprises stakeholders Communicate scenario, time, and possible impact in advance.

    Timing: Part of the agreed work block; research may be separate.

  3. 3

    Execution

    Run the scenario under control

    Goal

    Is real user protection maintained?

    Inputs for this step

    • Monitoring, observer log, and user-impact limit

    Actions

    • Inject the planned fault, observe system and response; stop if safety thresholds are breached.
    • Is real user protection maintained?

    Output

    Observed system and team response

    Observed system and team response

    Quality check

    Is real user protection maintained?

    Pitfall

    Only technology is exercised Include operations, communications, and decision roles.

    Timing: Part of the agreed work block; research may be separate.

  4. 4

    Learning

    Track learning

    Goal

    Do gaps feed procedures and the next exercise?

    Inputs for this step

    • Findings, remediations, and next exercise date

    Actions

    • Restore normal state; capture observations, actions, owners, and next exercise date.
    • Do gaps feed procedures and the next exercise?

    Output

    Tracked findings and retest plan

    Tracked findings and retest plan

    Quality check

    Do gaps feed procedures and the next exercise?

    Pitfall

    Findings are not fed back Feed actions into runbooks, alerting, and the next scenario.

    Timing: Part of the agreed work block; research may be separate.

05

Artifact

What comes out at the end

Sketch: what the artifact looks like

Game Day · kontrollierter Resilience-TestGeplante Störungen einspielen, Teamreaktion beobachten, Runbooks prüfen und Lernen ableiten
Game DayDas Visual zeigt kontrollierte Störungen, Teamreaktion, Runbook-Prüfung, Messwerte und Lernpunkte.Resilienz unter kontrollierter Störung übenGame Days testen Reaktion, Tools und Runbooks, bevor ein echter Vorfall Druck erzeugt.StörungAlarmanwendenReviewProduktionsnahes Systemsichere TestgrenzenInjectLatenz, Ausfall, QueueTeamreaktionIncident-Rollen übenRunbook prüfenSchritte, Lücken, ZeitLernenFixes, Training,nächste ÜbungMTTD4 minMTTR18 minBlast Radiusbegrenzt
Form

Versioned result with question, evidence, open issues, next action, ownership, and review date.

Versioning / ownership

Record date, scope, sources, and changes. Preserve earlier observations.

Tool alternatives
  • Whiteboard or paper
  • Shared spreadsheet
  • Versioned project space

game-day-working-template.md

Prepare Game Day with a clear question, roles, and sources.

Game Day: Worksheet

Question

To be confirmed

Desired outcome

To be confirmed

Scope

Plan the full method Time: Set according to scope and available evidence

Complete this worksheet on paper or in your own document during the work.

Preparation for this scope

Method setup

  • Materials: Shared workspace, accessible sources, and a decision log.
  • Roles: Exercise lead · safety lead · response team · observers
  • Advance information: Clarify the question, timeframe, data access, roles, and known uncertainties in advance.
  • Overall time needed: Recurring exercise; plan preparation, execution, recovery, and action review separately.
  • Setup: Create a shared version. Label facts, assumptions, and decisions separately.

Prepare for the work steps

Objective: Choose objective and risk

  • Resilience goal, service criticality, and risk

Boundaries: Prepare participants and stop controls

  • Approved scenario, participants, and kill switch

Execution: Run the scenario under control

  • Monitoring, observer log, and user-impact limit

Learning: Track learning

  • Findings, remediations, and next exercise date

Safety-bounded scenario and exercise learning

Scenario

State learning goal, service, scenario, and environment.

...

Safety boundary

Define participants, observation, kill switch, and thresholds.

...

Expected signals

Capture alerts, system state, and response during exercise.

...

Learning

Record recovery, findings, owners, and next exercise.

...

Blank worksheet: start with a bounded question. Enter observed facts only, mark assumptions, and record open questions and sources.

Conduct game days regularly · AWS Well-Architected

Objective: Choose objective and risk

Expected artifact: Bounded, approved failure scenario

Bounded, approved failure scenario

Entry:

...

  • Is the scenario approved and bounded?

Boundaries: Prepare participants and stop controls

Expected artifact: Participant, communications, and safety plan

Participant, communications, and safety plan

Entry:

...

  • Can anyone stop the exercise?

Execution: Run the scenario under control

Expected artifact: Observed system and team response

Observed system and team response

Entry:

...

  • Is real user protection maintained?

Learning: Track learning

Expected artifact: Tracked findings and retest plan

Tracked findings and retest plan

Entry:

...

  • Do gaps feed procedures and the next exercise?

Open questions and next steps

...

Method guide: https://methodatlas.meierhoff-systems.de/en/methods/game-day/run-sheet

06

Example output

Concrete filled scenario, fictional example

Fictional example for orientation. Counts and timings describe this case and are not universal requirements.

game-day-beispiel.md

Concrete filled scenario, fictional example

Fictional worked example

Fictional exercise: a read-only dependency fails in a production-like test environment. Goal: detect alert, activate fallback, keep user impact under 5 minutes. Safety lead can stop at any time. Exercise reveals a missing dashboard alert; no production traffic is injected.

All names and values are invented for illustration. Unresolved explanations remain questions.

07

Pitfalls

Recognize symptoms and steer against them

Quick overview, the full text is in the matching phase in the flow

  1. Choose objective and riskFault injected beyond safe boundaryView in phase
  2. Prepare participants and stop controlsExercise surprises stakeholdersView in phase
  3. Run the scenario under controlOnly technology is exercisedView in phase
  4. Track learningFindings are not fed backView in phase
08

Stop criteria

When to pause, resolve prerequisites, or choose another approach

The question or boundary remains ambiguous: narrow it first.
Key data or participants are missing: label the gap and arrange access.
The group mixes observation and explanation: revisit the evidence.
An immediate safety or operational risk appears: stop and use the responsible procedures.

Method after Praxisgemeinschaft. The method emerged as a widespread practice and is not clearly attributed to a single originator or organization. Curated with 1 sources.

Sources: Conduct game days regularly · AWS Well-Architected

Flow, timeboxes, and pitfalls are editorially curated practice recommendations based on the listed sources.

Where to go next?

Incident Command workspace showing the question, observations, and next decision.
DevOps
Incident Command

Carries the rehearsed coordination further into a real response.

Blameless Postmortem workspace showing the question, observations, and next decision.
DevOps
Blameless Postmortem

Examines unexpected behavior that surfaced during the exercise.

View in playbookImprove the Deployment and Platform FlowMove from a simulated outage through practiced incident response to a documented, improved learning loop.

Finished the method guide?

Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.

Go to profileMore methods