Chaos engineering

In short: Chaos engineering tests through targeted, controlled disruptions (switching off servers, delaying the network) whether a system really survives failures.

In more detail: You state a hypothesis (“if a server fails, the error rate stays below 0.1 %”), run a small experiment in a controlled environment and observe. If you find weaknesses you fix them before they occur in a real outage.

In Depth

• Process: Measure steady state → hypothesis → inject disruption → observe deviation → learn.
• Experiments: Terminate instances, add latency, shut down a dependency, fill the disk, shift the clock.
• Blast radius: Limit the effect, start small, be able to abort at any time.
• Game days: Planned exercises with the team.
• Tools: Chaos Monkey, Litmus, Gremlin, toxiproxy.
• Prerequisite: Monitoring and alerts, otherwise you see nothing.

See also: SLI, SLO and error budget, Circuit breaker and backpressure