methodatlas
Method guideEngineering

Failure Scenario Analysis

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

ComplexityMedium
Time1-3 h
Participants3-8
FormatWorkshop
MaturityEstablished
Plan Failure Scenario Analysis
01

Prerequisite

What needs to be finished first

Complete firstClear boundary

Set critical service, operating state, guardrails, and horizon; prepare incidents and architecture.

Without a boundary, cases, periods, or variables become mixed.
Complete firstEvidence access

System boundary, critical services, architecture/dependencies, scenario cards, signals, protections, and drill plan

Missing sources remain visible as uncertainty.
02

Preparation

What needs to be ready before start

Materials

System boundary, critical services, architecture/dependencies, scenario cards, signals, protections, and drill plan

People / roles

Service owner · reliability/safety · architecture · operations · affected domain perspectives · action owners

Pre-read

Set critical service, operating state, guardrails, and horizon; prepare incidents and architecture.

Time needed

90–180 minutes per system area; add technical validation and drills.

Setup

Prepare a workspace with Service · Scenarios · Paths · Protection · Exercise; separate example from live data.

03

Core question

The one question this method answers

Which credible failure paths threaten a critical service, how will we detect and limit them, and which residual uncertainty needs rehearsal?

04

Flow

Phases with goal, actions, output and pitfall

Failure scenario analysis models plausible disruptions as paths through a system and examines triggers, effects, and existing barriers. It highlights where layered protection or resilience work is needed.

Failure Scenario Analysis · working structure

Fictional example

Fictional values show the actual method fields.

Failure Scenario Analysis · working structure
ScenarioTriggerFailure pathImpactDetectionProtectionRecoveryExercise
Pool exhaustionAdd evidence and rationale.Batch startBatch → 72 connections → pool 95% → timeoutReserved pickup >15 minutesPool alert missingPool separation and circuit breakerPause batch; drain poolGameDay with 5% stop rule
Warehouse network downAdd evidence and rationale.Switch failureScanner offline → inventory unknown → handoff stopsNo confirmed handoffHeartbeat after 2 minutesOffline list, four-eyes checkPaper process; reconcile laterNetwork-loss tabletop

  1. 1. Trigger

    Pool exhaustion
    Batch start
    Warehouse network down
    Switch failure

  2. 2. Failure path

    Pool exhaustion
    Batch → 72 connections → pool 95% → timeout
    Warehouse network down
    Scanner offline → inventory unknown → handoff stops

  3. 3. Impact

    Pool exhaustion
    Reserved pickup >15 minutes
    Warehouse network down
    No confirmed handoff

  4. 4. Detection

    Pool exhaustion
    Pool alert missing
    Warehouse network down
    Heartbeat after 2 minutes

  5. 5. Protection

    Pool exhaustion
    Pool separation and circuit breaker
    Warehouse network down
    Offline list, four-eyes check

  6. 6. Recovery

    Pool exhaustion
    Pause batch; drain pool
    Warehouse network down
    Paper process; reconcile later

  7. 7. Exercise

    Pool exhaustion
    GameDay with 5% stop rule
    Warehouse network down
    Network-loss tabletop

All values are fictional.

Reference · original teaching example

  1. 1

    Service

    Protected outcome

    Goal

    Protected outcome: Define critical service, success criterion, and unacceptable impacts.

    Inputs for this step

    • Set critical service, operating state, guardrails, and horizon; prepare incidents and architecture.
    • System boundary, critical services, architecture/dependencies, scenario cards, signals, protections, and drill plan

    Actions

    • Define critical service, success criterion, and unacceptable impacts.

    Output

    Protected outcome

    Define critical service, success criterion, and unacceptable impacts.

    Quality check

    Is it clear what must be preserved under which conditions?

    Pitfall

    A component rather than user service is protected. Phrase protected outcome as experienced service plus boundary.

    Timing: 15–25 minutes

  2. 2

    Scenarios

    Scenario space

    Goal

    Scenario space: Collect credible triggers from architecture, history, and environment; include compound cases.

    Inputs for this step

    • Protected outcome

    Actions

    • Collect credible triggers from architecture, history, and environment; include compound cases.

    Output

    Scenario space

    Collect credible triggers from architecture, history, and environment; include compound cases.

    Quality check

    Are scenarios concrete, plausible, and distinguishable?

    Pitfall

    Only known single-component failures are considered. Add dependencies, common causes, and human-technical combinations.

    Timing: 25–40 minutes

  3. 3

    Paths

    Failure paths

    Goal

    Failure paths: Model trigger through intermediate states to impact; mark assumptions and escalation points.

    Inputs for this step

    • Scenario space

    Actions

    • Model trigger through intermediate states to impact; mark assumptions and escalation points.

    Output

    Failure paths

    Model trigger through intermediate states to impact; mark assumptions and escalation points.

    Quality check

    Is each connection mechanistic and time-aware?

    Pitfall

    Scenario jumps from trigger to harm. Add intermediate states, time, and necessary conditions.

    Timing: 25–45 minutes

  4. 4

    Protection

    Protection matrix

    Goal

    Protection matrix: Check detection, prevention, mitigation, and recovery per path; mark single points and blind spots.

    Inputs for this step

    • Failure paths

    Actions

    • Check detection, prevention, mitigation, and recovery per path; mark single points and blind spots.

    Output

    Protection matrix

    Check detection, prevention, mitigation, and recovery per path; mark single points and blind spots.

    Quality check

    Does each control have signal, owner, and known limit?

    Pitfall

    A runbook existing counts as effective protection. Evidence control via test, last use, and failure mode.

    Timing: 25–45 minutes

  5. 5

    Exercise

    Drill plan

    Goal

    Drill plan: Run prioritised scenarios as tabletop, GameDay, or technical test with stop rules.

    Inputs for this step

    • Protection matrix

    Actions

    • Run prioritised scenarios as tabletop, GameDay, or technical test with stop rules.

    Output

    Drill plan

    Run prioritised scenarios as tabletop, GameDay, or technical test with stop rules.

    Quality check

    Does drill test detection, decision, recovery, and communication?

    Pitfall

    Risks remain only in register. Schedule safe drill, measures, and follow-up.

    Timing: 20–30 minutes

05

Artifact

What comes out at the end

Sketch: what the artifact looks like

Failure Scenario AnalysisPlausible Ausfälle als Szenarien mit Auslösern, Auswirkungen, Kontrollen, Lücken und Response-Tests modellieren
Failure Scenario AnalysisDas Visual zeigt ein abgegrenztes System, einen plausiblen Ausfallpfad mit Auslöser, Ausfall und Impact sowie Kontrollen, Lücken und Response-Test.Plausible Ausfälle als prüfbare Szenarien vorbereitenDie Analyse macht sichtbar, wie ein System scheitern könnte, welche Kontrollen wirken und welche Response geprobt werden muss.konkrete GeschichteKontrollen und Lücken sichtbar machenSystemgrenzekritischer Prozess oderReleaseFailure Scenariorealistischer AusfallpfadAuslöserLastspitzeAusfallQueue läuft vollImpactCheckout blockiertKontrolleAutoscaling und AlarmLückeRunbook fehltResponse-TestGame Day oder Probealarm planen
Form

Failure-scenario register with trigger, path, impact, detection, protection, recovery, residual risk, and drill.

Versioning / ownership

Record date, owner, source state, and review date; preserve prior versions.

Tool alternatives
  • Scenario and path cards
  • Detection/protection/recovery matrix
  • Drill and action log

failure-scenario-analysis-working-template.md

Set subject, evidence, roles, flow, and review.

Failure Scenario Analysis: Worksheet

Question

To be confirmed

Desired outcome

To be confirmed

Scope

Complete run Time: 90–180 minutes per system area; add technical validation and drills.

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

Preparation for this scope

Method setup

  • Materials: System boundary, critical services, architecture/dependencies, scenario cards, signals, protections, and drill plan
  • Roles: Service owner · reliability/safety · architecture · operations · affected domain perspectives · action owners
  • Advance information: Set critical service, operating state, guardrails, and horizon; prepare incidents and architecture.
  • Overall time needed: 90–180 minutes per system area; add technical validation and drills.
  • Setup: Prepare a workspace with Service · Scenarios · Paths · Protection · Exercise; separate example from live data.

Prepare for the work steps

Service: Protected outcome

  • Set critical service, operating state, guardrails, and horizon; prepare incidents and architecture.
  • System boundary, critical services, architecture/dependencies, scenario cards, signals, protections, and drill plan

Scenarios: Scenario space

  • Protected outcome

Paths: Failure paths

  • Scenario space

Protection: Protection matrix

  • Failure paths

Exercise: Drill plan

  • Protection matrix

Failure Scenario Analysis · working structure

ScenarioTriggerFailure pathImpactDetectionProtectionRecoveryExercise
Pool exhaustion
Warehouse network down
  • Pool exhaustion: Add evidence and rationale.
  • Warehouse network down: Add evidence and rationale.

The blank worksheet contains prompts only.

Reference · original teaching example

Service: Protected outcome

Expected artifact: Protected outcome

Define critical service, success criterion, and unacceptable impacts.

Entry:

...

  • Is it clear what must be preserved under which conditions?

Scenarios: Scenario space

Expected artifact: Scenario space

Collect credible triggers from architecture, history, and environment; include compound cases.

Entry:

...

  • Are scenarios concrete, plausible, and distinguishable?

Paths: Failure paths

Expected artifact: Failure paths

Model trigger through intermediate states to impact; mark assumptions and escalation points.

Entry:

...

  • Is each connection mechanistic and time-aware?

Protection: Protection matrix

Expected artifact: Protection matrix

Check detection, prevention, mitigation, and recovery per path; mark single points and blind spots.

Entry:

...

  • Does each control have signal, owner, and known limit?

Exercise: Drill plan

Expected artifact: Drill plan

Run prioritised scenarios as tabletop, GameDay, or technical test with stop rules.

Entry:

...

  • Does drill test detection, decision, recovery, and communication?

Open questions and next steps

...

Method guide: https://methodatlas.meierhoff-systems.de/en/methods/failure-scenario-analysis/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.

failure-scenario-analysis-beispiel.md

Concrete filled scenario, fictional example

Fictional teaching example: Failure Scenario Analysis · working structure

ScenarioTriggerFailure pathImpactDetectionProtectionRecoveryExercise
Pool exhaustionBatch startBatch → 72 connections → pool 95% → timeoutReserved pickup >15 minutesPool alert missingPool separation and circuit breakerPause batch; drain poolGameDay with 5% stop rule
Warehouse network downSwitch failureScanner offline → inventory unknown → handoff stopsNo confirmed handoffHeartbeat after 2 minutesOffline list, four-eyes checkPaper process; reconcile laterNetwork-loss tabletop
07

Pitfalls

Recognize symptoms and steer against them

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

  1. Protected outcomeA component rather than user service is protected.View in phase
  2. Scenario spaceOnly known single-component failures are considered.View in phase
  3. Failure pathsScenario jumps from trigger to harm.View in phase
  4. Protection matrixA runbook existing counts as effective protection.View in phase
  5. Drill planRisks remain only in register.View in phase
08

Stop criteria

When to pause, resolve prerequisites, or choose another approach

Stop Service: Is it clear what must be preserved under which conditions?
Stop Scenarios: Are scenarios concrete, plausible, and distinguishable?
Stop Paths: Is each connection mechanistic and time-aware?
Stop Protection: Does each control have signal, owner, and known limit?
Stop Exercise: Does drill test detection, decision, recovery, and communication?

Method after Reliability Engineering Community. Curated with 1 sources.

Sources: Failure Scenario Analysis

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

Where to go next?

Game Day workspace showing the question, observations, and next decision.
DevOps
Game Day

Turns the prioritized failure scenarios into a realistic GameDay exercise.

Runbook workspace showing the question, observations, and next decision.
Operations
Runbook

Captures protective mechanisms and response steps for the identified scenarios as a runbook.

View in playbookConduct Risk and Readiness ReviewMove from optimism to visible risks, controls, tests, and release decision.

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