Method guideEngineering

Fault Isolation

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

ComplexityMedium

Time30-180 min

Participants1-6

FormatWorkshop + async

MaturityEstablished

Plan Fault Isolation

Prerequisite

What needs to be finished first

Complete firstClear boundary

Set symptom, success/failure criterion, affected and unaffected cases, and safe test boundaries.

Without a boundary, cases, periods, or variables become mixed.

Complete firstEvidence access

Symptom and reproduction, architecture/dependency map, comparison signals, safe tests, and isolation log

Missing sources remain visible as uncertainty.

Preparation

What needs to be ready before start

Materials

Symptom and reproduction, architecture/dependency map, comparison signals, safe tests, and isolation log

People / roles

Troubleshooting lead · system/component experts · operator · scribe

Pre-read

Set symptom, success/failure criterion, affected and unaffected cases, and safe test boundaries.

Time needed

30–180 minutes per failure; duration depends on test access and system complexity.

Setup

Prepare a workspace with Boundary · Candidates · Split · Test · Confirm; separate example from live data.

Core question

The one question this method answers

Which smallest subsystem contains the fault when candidates are systematically excluded through discriminating tests?

Flow

Phases with goal, actions, output and pitfall

Fault isolation narrows system boundaries, symptoms, and candidate fault areas so tests can target the likely origin. Each exclusion reduces the candidate space and makes the remaining domain more tangible.

Fault Isolation · working structure

Fictional example

Fictional values show the actual method fields.

Fault Isolation · working structure
Test	Candidates before	Test change	Discriminating prediction	Result	Excluded	Remaining
Direct API callAdd evidence and rationale.	Frontend, API, pool, DB, network	Bypass frontend	Fails if backend path is faulty	Timeout remains	Frontend	API, pool, DB, network
Isolated poolAdd evidence and rationale.	API, pool, DB, network	Change pool path only	Failure disappears for shared-pool fault	Checkout works	API, DB, network	Shared pool

1. Candidates before
Direct API call
Frontend, API, pool, DB, network
Isolated pool
API, pool, DB, network
2. Test change
Direct API call
Bypass frontend
Isolated pool
Change pool path only
3. Discriminating prediction
Direct API call
Fails if backend path is faulty
Isolated pool
Failure disappears for shared-pool fault
4. Result
Direct API call
Timeout remains
Isolated pool
Checkout works
5. Excluded
Direct API call
Frontend
Isolated pool
API, DB, network
6. Remaining
Direct API call
API, pool, DB, network
Isolated pool
Shared pool

All values are fictional.

Reference · original teaching example

1
Boundary
Fault boundary
Goal
Fault boundary: Describe reproducible symptom and collect Is/Is-Not cases.
Inputs for this step
- Set symptom, success/failure criterion, affected and unaffected cases, and safe test boundaries.
- Symptom and reproduction, architecture/dependency map, comparison signals, safe tests, and isolation log
Actions
- Describe reproducible symptom and collect Is/Is-Not cases.
Output
Fault boundary
Describe reproducible symptom and collect Is/Is-Not cases.
Quality check
Are affected, unaffected, and trigger concrete?
Pitfall
Checkout broken is too broad. Slice by region, channel, time, and dependency.
Timing: 10–20 minutes
2
Candidates
Candidate map
Goal
Candidate map: Map dependency path and collect plausible fault domains without fixing cause.
Inputs for this step
- Fault boundary
Actions
- Map dependency path and collect plausible fault domains without fixing cause.
Output
Candidate map
Map dependency path and collect plausible fault domains without fixing cause.
Quality check
Does map cover signal path end to end?
Pitfall
Team jumps to the latest changed component. Draw full path and order candidates by signal boundary.
Timing: 15–25 minutes
3
Split
Isolation plan
Goal
Isolation plan: Choose the most discriminating test, preferably safe bisection or affected/unaffected comparison.
Inputs for this step
- Candidate map
Actions
- Choose the most discriminating test, preferably safe bisection or affected/unaffected comparison.
Output
Isolation plan
Choose the most discriminating test, preferably safe bisection or affected/unaffected comparison.
Quality check
Will either result exclude several candidates?
Pitfall
Many measurements are collected without decision logic. State which result excludes which domains before testing.
Timing: 10–20 minutes
4
Test
Isolation log
Goal
Isolation log: Run one test at a time, record result and side effect, and update candidate space.
Inputs for this step
- Isolation plan
Actions
- Run one test at a time, record result and side effect, and update candidate space.
Output
Isolation log
Run one test at a time, record result and side effect, and update candidate space.
Quality check
Was only one distinguishing condition changed?
Pitfall
Several components restart together. One change per test; label diagnostic value of emergency action.
Timing: 15–90 minutes
5
Confirm
Confirmed domain
Goal
Confirmed domain: Confirm isolated area by reproduction or controlled return and hand over residual uncertainty.
Inputs for this step
- Isolation log
Actions
- Confirm isolated area by reproduction or controlled return and hand over residual uncertainty.
Output
Confirmed domain
Confirm isolated area by reproduction or controlled return and hand over residual uncertainty.
Quality check
Does symptom occur with the domain and disappear without it?
Pitfall
Isolation is confused with root cause. Confirm fault domain and investigate causal mechanism separately.
Timing: 15–30 minutes

Artifact

What comes out at the end

Sketch: what the artifact looks like

Fault Isolation · Narrowing DownBreak the fault space into testable system areas, run targeted tests, and document excluded areas visibly

Form

Fault-isolation log with candidate space, tests, results, excluded areas, and isolated fault domain.

Versioning / ownership

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

Tool alternatives

System/dependency map
Binary isolation plan
Test and exclusion log

fault-isolation-working-template.md

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

Fault Isolation: Worksheet

Question

To be confirmed

Desired outcome

To be confirmed

Scope

Complete run Time: 30–180 minutes per failure; duration depends on test access and system complexity.

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

Preparation for this scope

Method setup

Materials: Symptom and reproduction, architecture/dependency map, comparison signals, safe tests, and isolation log
Roles: Troubleshooting lead · system/component experts · operator · scribe
Advance information: Set symptom, success/failure criterion, affected and unaffected cases, and safe test boundaries.
Overall time needed: 30–180 minutes per failure; duration depends on test access and system complexity.
Setup: Prepare a workspace with Boundary · Candidates · Split · Test · Confirm; separate example from live data.

Prepare for the work steps

Boundary: Fault boundary

Set symptom, success/failure criterion, affected and unaffected cases, and safe test boundaries.
Symptom and reproduction, architecture/dependency map, comparison signals, safe tests, and isolation log

Candidates: Candidate map

Fault boundary

Split: Isolation plan

Candidate map

Test: Isolation log

Isolation plan

Confirm: Confirmed domain

Isolation log

Fault Isolation · working structure

Test	Candidates before	Test change	Discriminating prediction	Result	Excluded	Remaining
Direct API call
Isolated pool

Direct API call: Add evidence and rationale.
Isolated pool: Add evidence and rationale.

The blank worksheet contains prompts only.

Reference · original teaching example

Boundary: Fault boundary

Expected artifact: Fault boundary

Describe reproducible symptom and collect Is/Is-Not cases.

Entry:

...

Are affected, unaffected, and trigger concrete?

Candidates: Candidate map

Expected artifact: Candidate map

Map dependency path and collect plausible fault domains without fixing cause.

Entry:

...

Does map cover signal path end to end?

Split: Isolation plan

Expected artifact: Isolation plan

Choose the most discriminating test, preferably safe bisection or affected/unaffected comparison.

Entry:

...

Will either result exclude several candidates?

Test: Isolation log

Expected artifact: Isolation log

Run one test at a time, record result and side effect, and update candidate space.

Entry:

...

Was only one distinguishing condition changed?

Confirm: Confirmed domain

Expected artifact: Confirmed domain

Confirm isolated area by reproduction or controlled return and hand over residual uncertainty.

Entry:

...

Does symptom occur with the domain and disappear without it?

Open questions and next steps

...

Method guide: https://methodatlas.meierhoff-systems.de/en/methods/fault-isolation/run-sheet

Example output

Concrete filled scenario, fictional example

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

fault-isolation-beispiel.md

Concrete filled scenario, fictional example

Fictional teaching example: Fault Isolation · working structure

Test	Candidates before	Test change	Discriminating prediction	Result	Excluded	Remaining
Direct API call	Frontend, API, pool, DB, network	Bypass frontend	Fails if backend path is faulty	Timeout remains	Frontend	API, pool, DB, network
Isolated pool	API, pool, DB, network	Change pool path only	Failure disappears for shared-pool fault	Checkout works	API, DB, network	Shared pool

Pitfalls

Recognize symptoms and steer against them

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

Fault boundaryCheckout broken is too broad.View in phase
Candidate mapTeam jumps to the latest changed component.View in phase
Isolation planMany measurements are collected without decision logic.View in phase
Isolation logSeveral components restart together.View in phase
Confirmed domainIsolation is confused with root cause.View in phase

Stop criteria

When to pause, resolve prerequisites, or choose another approach

Stop Boundary: Are affected, unaffected, and trigger concrete?

Stop Candidates: Does map cover signal path end to end?

Stop Split: Will either result exclude several candidates?

Stop Test: Was only one distinguishing condition changed?

Stop Confirm: Does symptom occur with the domain and disappear without it?

Where to go next?

Engineering

Hypothesis-Driven Troubleshooting

Uses the confirmed domain to form targeted hypotheses and tests for the mechanism.

Operations

Runbook

Captures the confirmed isolation path as a repeatable procedure for future cases.

View in playbookSystematically Improve Engineering QualityMove from a vague quality goal through visible flow and tested hypotheses to a durably anchored standard path.

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 profile More methods

Fault Isolation · working structure

1. Candidates before

2. Test change

3. Discriminating prediction

4. Result

5. Excluded

6. Remaining

Fault boundary

Candidate map

Isolation plan

Isolation log

Confirmed domain

fault-isolation-working-template.md

Fault Isolation: Worksheet

Question

Desired outcome

Scope

Preparation for this scope

Method setup

Prepare for the work steps

Boundary: Fault boundary

Candidates: Candidate map

Split: Isolation plan

Test: Isolation log

Confirm: Confirmed domain

Fault Isolation · working structure

Boundary: Fault boundary

Candidates: Candidate map

Split: Isolation plan

Test: Isolation log

Confirm: Confirmed domain

Open questions and next steps

fault-isolation-beispiel.md

Fictional teaching example: Fault Isolation · working structure

Fault boundary

Candidate map

Isolation plan

Isolation log

Confirmed domain

Where to go next?

Finished the method guide?