Chaos engineering: test one recovery assumption

An application may look healthy until a process stops or a dependency disappears. Chaos engineering tests a specific recovery assumption by introducing a controlled failure and observing what users experience.

For a first exercise, use a disposable service and ask a simple question: if one application copy stops, do requests still succeed while it is replaced? Define what you expect, what you will measure, when to stop and how to restore the starting state. Choose this approach when you have a recovery claim to test, not merely a desire to break something.

Try it in a lab

Choose a disposable application and define one harmless failure, such as terminating one replica. Record the expected user-visible behavior, observe recovery and restore the baseline.

Check your understanding

Compare the observed result with the hypothesis and explain how the stop condition would have limited impact. Preserve the configuration and timeline needed to repeat the experiment.

Before you start

Begin in an isolated lab. Do not introduce production failure or affect another team without explicit authorization and operational safeguards.

Read the official guide

Read Principles of Chaos Engineering for experiment design, steady-state hypotheses and limiting the affected scope. It is a principles reference, not a source of version-specific commands; use the documentation for your chosen platform or fault-injection tool for those. Record the versions and results of your own exercise. This page proposes a learning activity; it does not report a Kubedex test.

This is a newly written study reference at an address from the original Kubedex course outline. The original lesson was not recovered. It does not include course enrolment, progress tracking or a certificate.