Skip to content

Defect-Injection Test

Audit — instantiates Mobile-Defect Reconfiguration

Deliberately introduces a bounded defect to probe where the machinery pins, breaks, or spreads — mapping barriers and blast radius before a real run depends on it.

Defect-Injection Test deliberately introduces a controlled defect into the substrate to learn how the reconfiguration machinery behaves before a real transition depends on it. By injecting a bounded, intentional fault and watching what happens, it discovers where a moving defect gets pinned (stuck at an obstacle), where a handoff fails, and how far damage spreads when something goes wrong. Its defining trait is that it is adversarial and pre-emptive: it does not wait for a real defect to reveal the weak points — it manufactures a safe one on purpose to map the barriers and measure the blast radius while the stakes are low.

Example

An engineering team relies on rolling migrations across a large microservice fleet, but nobody is sure the machinery survives contact with reality. So they run a Defect-Injection Test in the spirit of chaos engineering: during a controlled window, they inject a deliberate fault — killing the migration coordinator mid-hop, or holding a lock open — into a bounded slice of the fleet, and watch. The test surfaces where the moving change pins: a service that never releases its old connection pool, a handoff that deadlocks when a downstream dependency is slow. It also measures the blast radius — how many requests errored, how far the disturbance propagated before containment caught it. The output is a map of pinning sites and a damage profile, produced on purpose in daylight rather than discovered by a real incident at 3 a.m.

How it works

  • Inject a bounded, intentional defect. A deliberate fault enters a limited slice, with a pre-set abort so the experiment itself can be stopped.
  • Watch where it pins. Observe where the injected defect gets stuck, deadlocks, or fails to hand off — those are the barriers a real transition will hit.
  • Measure the spread. Quantify how far the disturbance propagates and how much it damages before containment engages — the blast radius.
  • Report the map, don't fix it. The test produces the pinning/barrier map and the damage profile; removing the barriers is a separate job.

Tuning parameters

  • Blast-radius bound — how large a slice the injected defect may affect. Bigger scope finds systemic faults but risks real harm; smaller scope is safe but may miss emergent failures.
  • Fault realism — how closely the injected defect mimics a plausible real one. More realistic faults are more informative and more dangerous.
  • Environment — staging versus production. Production injection finds real barriers that staging hides, at real risk.
  • Abort sensitivity — how quickly the experiment self-terminates when damage exceeds expectation.

When it helps, and when it misleads

Its strength is that it converts unknown fragility into a concrete map: you learn where the machinery pins and how bad a failure gets before a real transition is riding on it. That is the whole premise of chaos engineering — inject controlled failure to surface weakness proactively.[1]

Run without a bounded blast radius or a working abort, the test becomes the incident it was meant to prevent. It is also easily misused to prove resilience — injecting only the faults the system already handles and declaring victory — rather than to find weakness, which requires injecting the faults you fear. And a test that maps barriers whose findings are never acted on is theatre. The discipline is a bounded blast radius, an explicit steady-state hypothesis and abort condition, injecting the failures you most doubt the system can absorb, and routing the findings to removal.

How it implements the components

  • pinning_and_barrier_map — the located obstacles where an injected (and therefore a real) defect gets stuck or fails to hand off.
  • progress_and_damage_metrics — the measured blast radius and damage profile the injected fault produces.

It maps and measures but does not clear the barriers it finds — removal is Pinning-Site Removal Procedure — and it is not the live operational readout of a real run, which is Mobile-Defect Progress Dashboard.

References

[1] Chaos engineering is the practice of injecting controlled failures into a system to reveal weaknesses before they cause real outages — typically framed around a steady-state hypothesis, a bounded blast radius, and a defined abort. That framing is what separates a test from an incident. ↩