Chaos Engineering Fundamentals
What this domain tests
This domain checks whether you understand chaos engineering as a controlled, hypothesis-driven discipline rather than ad hoc fault testing. For Harness Certified Chaos Engineering, expect questions on the experiment lifecycle, the role of a steady-state hypothesis, how Harness Chaos Engineering represents faults, experiments, probes, and resilience scores, and why production experimentation is bounded by safety controls.
Core rules
- Start with a measurable steady state: user-facing indicators such as error rate, latency, throughput, or saturation, not merely pod status.
- State a falsifiable hypothesis: within a defined window and blast radius, the system's steady state will not deviate beyond tolerance.
- Inject a realistic fault, observe, compare treatment with baseline or control, then conclude, abort, or roll back.
- Automate experiments and repeat them; a single successful run is evidence, not proof.
- In Harness CE, a chaos infrastructure (delegate-based runner in the target environment) executes experiments; faults come from ChaosHub or custom definitions; probes evaluate the hypothesis; the resilience score summarizes probe outcomes.
- Safety is part of the method: target selectors, duration limits, abort conditions, approvals, and guardrails.
Worked example
A checkout API has a baseline p95 latency of 240 ms and a 0.4% error rate. The team hypothesizes that deleting one of four pods for two minutes will keep p95 below 500 ms and errors below 1%. They define probes for both metrics, target a single pod by label, set the experiment to abort if errors exceed 2%, and run it during low traffic. The result: p95 rises to 310 ms and errors to 0.6%; the hypothesis passes. The reasoning is that the steady state was measured before injection, the fault was bounded, and the pass/fail rule was defined in advance rather than after seeing the graph.
Traps
- Calling any fault injection "chaos" without a hypothesis or baseline.
- Measuring causes (CPU, pod count) instead of user-visible symptoms.
- Defining success criteria after the run, or changing thresholds to make the result pass.
- Running in production without abort criteria, approvals, or a narrow target.
- Treating the resilience score as an absolute availability guarantee; it reflects the probes and weights configured for that experiment.