Engineering Analysis method

Fault Isolation

Fault isolation narrows the fault space and symptoms until only a few hypotheses and targeted tests remain.

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.

Core question

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

Plan Fault Isolation Method guide

Start comparison

Give feedbackIs this method useful to you?

Participants: 1-6
Time: 30–180 minutes per failure; duration depends on test access and system complexity.

The steps form one complete method run.

Boundary
Fault boundary
Describe reproducible symptom and collect Is/Is-Not cases.
Candidates
Candidate map
Map dependency path and collect plausible fault domains without fixing cause.
Split
Isolation plan
Choose the most discriminating test, preferably safe bisection or affected/unaffected comparison.
Test
Isolation log
Run one test at a time, record result and side effect, and update candidate space.
Confirm
Confirmed domain
Confirm isolated area by reproduction or controlled return and hand over residual uncertainty.

Add new evidence at review and version decisions with the prior state.

A good fit when

Bei technischen Störungen vermischt sich oft das sichtbare Symptom mit der eigentlichen Ursache. Fault Isolation grenzt den Fehlerraum ein und reduziert schrittweise, welcher Teil des Systems wirklich betroffen ist.

Ideal for

Technical troubleshooting
Integration failures
System outages

Not good for

Open strategy questions
Non-testable conflicts
Pure ideation

Outputs

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

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

First step

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

Open the method guide

Good to do first

Operations

Change Analysis

Supplies comparison cases and suspected changes that guide narrowing the fault space.

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.

Deep dive

Purpose

In technical failures, the visible symptom often gets mixed up with the actual cause. Fault Isolation narrows the fault space and progressively reduces which part of the system is truly affected.

How it works

System boundaries, symptoms, and possible fault areas are set against each other so tests act in a targeted way instead of broadly. With each exclusion, the space shrinks until the likely origin becomes tangible. The procedure saves time because it replaces speculation with narrowing down.

In detail

Fault Isolation works by narrowing the search instead of guessing. A complex system is broken down into components, interfaces, states, and dependencies. Through targeted tests, comparisons, and control questions, the possible error area is gradually reduced. The result is not the root cause right away, but a well-narrowed location or mechanism.

Facilitation

Start with a system sketch and clear symptoms. Plan tests so that each one truly reduces the fault space. Document excluded areas so the team does not keep testing the same hypotheses.

The method guide walks execution through 5 phases, timing, 5 pitfalls, and clear stop criteria.

Open method guide

Your perspective

Does this method help with your work?

Your feedback helps shape the next improvements to methodatlas.

Sources and topics

Topics

Troubleshooting Diagnosis Engineering

Sources

Fault Isolationsre.googleGoogle's SRE Book (O'Reilly), chapter by Chris Jones; describes the hypothetico-deductive method for systematic troubleshooting.

In playbooks

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

Artifact templates

Fault Isolation: WorksheetSet subject, evidence, roles, flow, and review.

markdown

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

Alternatives and neighbors

Fitting alternatives with decision guidance, followed by other related methods.

All methods

Operations

Root Cause Analysis

Instead of Fault Isolation, choose Root Cause Analysis when you want to systematically narrow down causes instead of stopping at symptoms.

Operations

Fault Tree Analysis

Instead of Fault Isolation, choose Fault Tree Analysis when failures should be broken down logically from top to bottom and individual tests are not enough anymore.

Engineering

Goal Question Metric

Moves technical problems, hypotheses, and next steps toward a concrete result through "formulate the goal clearly", "derive probing questions for each goal", and "set the review cadence".