Production systems fail in ways engineers do not anticipate during design. Dependencies go unreachable, disks fill silently, network packets experience latency spikes at statistically unlikely moments, and cascading failures emerge from interactions between components that are individually well-behaved. Conventional responses — writing more tests, adding more monitoring — address known failure modes but leave unknown ones undiscovered until a production incident reveals them.
Chaos engineering addresses this gap by deliberately injecting controlled failures into production or production-equivalent environments and observing whether the system behaves according to its steady-state hypothesis. The key word is 'controlled': chaos engineering is not random destruction but a scientific experimental process with defined hypotheses, blast radius constraints, automatic rollback conditions, and formal result documentation.
Practised correctly, it transforms the question from 'is our system resilient?' — which can only be answered after an uncontrolled incident — to 'in what specific ways is our system resilient, and under what conditions does that resilience break down?'