methodatlas
Session Builder

Plan my session

Plan a concrete work block with agenda, roles, preparation, and a copyable result artifact.

Method session4-8 h for a game day, plus 1-2 weeks preparationWorkshopSimulation Notes

Session: Game Day

The plan translates the method into a concrete facilitated work block. Your inputs flow directly into the session brief and work artifact.

Derived automatically

Method session with 5-20. The plan uses the existing method logic and the runsheet.

Runsheet
Participation logic
Team round, shared work and alignment

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome logic
Finish artifact

The session works directly toward Simulation Notes. After the session, the artifact should be shareable, reviewable, or reusable.

  1. 1

    Phase 1: Script and hypotheses

    3-5 days lead time

    Define three to five scenarios (for example DB failover, pod crash, region outage). For each scenario define hypothesis, expected result, and success criteria (for example recovery in 5 min). Hint: Write hypothesis explicitly. If no one states expected behavior before start, no surprise can be learned.

    FacilitatorSimulation Notes
  2. 2

    Phase 2: Setup and safety brief

    30 min

    Verify observability stack. Assign roles. Clarify Big Red Button criteria (for example real customer impact above threshold X). Communicate to stakeholders. Hint: If stakeholders are not informed, a real alert can trigger escalations outside the exercise. Clear labeling is required.

    FacilitatorGaps List
  3. 3

    Phase 3: Injection and response

    2-4 h

    Scenario by scenario: inject failure, team responds with runbook, observers log response times, decisions, and tool behavior. Game day master delays recovery when appropriate. Hint: Maintain realism. When participants know it is an exercise, adrenaline drops. Still, avoid too long delays to prevent frustration.

    FacilitatorUpdated Runbooks
  4. 4

    Phase 4: Recovery and verification

    30-60 min

    After each scenario, team performs controlled recovery. Observers check whether monitoring detected the failure and runbook worked. Hint: Recovery is part of the exercise. If recovery fails, the runbook has a gap. When complete standby outage happens, safety officer triggers Big Red Button.

    FacilitatorSimulation Notes
  5. 5

    Phase 5: Debrief and follow-ups

    60-90 min

    Run after-action review per scenario: plan vs reality, root causes, lessons, actions. Create tickets with owner and deadline for top-3 lessons. Plan runbook updates. Hint: Lessons without follow-up waste the game day. Limit to three actions per game day, otherwise follow-through disappears.

    OwnerGaps List
  6. 6

    Publish artifact

    10 min

    Check the artifact for completeness, define location, set version or status, and name review recipients.

    OwnerSimulation Notes
Usable artifact

Session Brief

For invitations, boards, tickets, PR descriptions, or workshop notes.

session-brief.md

Session Brief: Game Day

Goal

Artifact: Simulation Notes

Working Question

How do system, tools, and team react to realistically injected failures, and which gaps in runbooks, monitoring, or roles become visible?

Context

Architecture diagram; SLO/SLA of affected services; known weaknesses from past incidents; current runbooks; pre-test health check.

Setup

  • Format: Method session
  • Duration: 4-8 h for a game day, plus 1-2 weeks preparation
  • Mode: Workshop
  • Participants: A game day master (script author); incident commander; operator team; observer for each relevant service; stakeholder representative; safety officer with abort authority.
  • Owner: A game day master (script author)
  • Participation mode: Team round, shared work and alignment
  • Outcome logic: Finish artifact

Participation Logic

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome Logic

The session works directly toward Simulation Notes. After the session, the artifact should be shareable, reviewable, or reusable.

Input

Failure-injection tools (Chaos Mesh, Gremlin, AWS Fault Injection Simulator); observability stack (Datadog, Grafana, logs); communication channel; scenario and expectation script; safety shutoff.

Preparation

Schedule date in calendar and inform all relevant stakeholders. Production mode: failure injection on staging or isolated tenant. Define safety abort conditions (big red button). Establish communication plan so real users are not startled.

Agenda

  1. Phase 1: Script and hypotheses (3-5 days lead time) Owner: Facilitator Action: Define three to five scenarios (for example DB failover, pod crash, region outage). For each scenario define hypothesis, expected result, and success criteria (for example recovery in 5 min). Hint: Write hypothesis explicitly. If no one states expected behavior before start, no surprise can be learned. Output: Simulation Notes

  2. Phase 2: Setup and safety brief (30 min) Owner: Facilitator Action: Verify observability stack. Assign roles. Clarify Big Red Button criteria (for example real customer impact above threshold X). Communicate to stakeholders. Hint: If stakeholders are not informed, a real alert can trigger escalations outside the exercise. Clear labeling is required. Output: Gaps List

  3. Phase 3: Injection and response (2-4 h) Owner: Facilitator Action: Scenario by scenario: inject failure, team responds with runbook, observers log response times, decisions, and tool behavior. Game day master delays recovery when appropriate. Hint: Maintain realism. When participants know it is an exercise, adrenaline drops. Still, avoid too long delays to prevent frustration. Output: Updated Runbooks

  4. Phase 4: Recovery and verification (30-60 min) Owner: Facilitator Action: After each scenario, team performs controlled recovery. Observers check whether monitoring detected the failure and runbook worked. Hint: Recovery is part of the exercise. If recovery fails, the runbook has a gap. When complete standby outage happens, safety officer triggers Big Red Button. Output: Simulation Notes

  5. Phase 5: Debrief and follow-ups (60-90 min) Owner: Owner Action: Run after-action review per scenario: plan vs reality, root causes, lessons, actions. Create tickets with owner and deadline for top-3 lessons. Plan runbook updates. Hint: Lessons without follow-up waste the game day. Limit to three actions per game day, otherwise follow-through disappears. Output: Gaps List

  6. Publish artifact (10 min) Owner: Owner Action: Check the artifact for completeness, define location, set version or status, and name review recipients. Output: Simulation Notes

Closeout

  • Update result artifact: Simulation Notes
  • Define location, version, and review recipients.
  • Define owner, next step, and review date.
Usable artifact

Work artifact

Pre-filled starting point based on the matching template.

work-artifact.md

Simulation Notes: Game Day

Working Question

How do system, tools, and team react to realistically injected failures, and which gaps in runbooks, monitoring, or roles become visible?

Context

Architecture diagram; SLO/SLA of affected services; known weaknesses from past incidents; current runbooks; pre-test health check.

Participants

  • Owner: A game day master (script author)
  • Participants: A game day master (script author); incident commander; operator team; observer for each relevant service; stakeholder representative; safety officer with abort authority.

Input

Failure-injection tools (Chaos Mesh, Gremlin, AWS Fault Injection Simulator); observability stack (Datadog, Grafana, logs); communication channel; scenario and expectation script; safety shutoff.

Template

Game Day Working Template

Goal

A realistic exercise to practice incident response and recovery.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Execution

Short notes along the runsheet.

Output artifacts

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

Assumptions and open questions

  • ...

Decision / Next step

Owner, date, and success signal.

Completion Check

  • Simulation Notes is complete enough for review:
  • Location:
  • Version / status:
  • Review by:
  • Next step:

Next Step

  • Review result
  • Mark open questions
  • Schedule review or decision
Template base

Game Day Working Template

View templateCompact working template for Game Day with context, input, output artifacts, and next step.
markdown

game-day-working-template.md

Compact working template for Game Day with context, input, output artifacts, and next step.

Game Day Working Template

Goal

A realistic exercise to practice incident response and recovery.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Execution

Short notes along the runsheet.

Output artifacts

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

Assumptions and open questions

  • ...

Decision / Next step

Owner, date, and success signal.

Ready to use when
  • Working question, owner, and target artifact are visible.
  • The result fits Simulation Notes.
  • One entry per game day with date, scenarios, and outcomes. Compare across game days (time-to-detect and time-to-mitigate trends). Link runbook versions before and after game day.
  • Open questions are noted as follow-ups.
  • The next review or decision point is scheduled.
ProfileRunsheet