Infrastructure: chaos engineering
Chaos engineering is a method: state a measurable hypothesis about steady state, inject one specific failure, observe, and stop if the hypothesis fails. This course applies that method to a single-server Rails application. It treats observability as the prerequisite and runs a paper experiment that traces the /up health check. It lists the failures this system can have and explains why blast radius cannot be limited on one container. It closes with an ordering of preconditions and a challenge about evaluating an experiment.
What you'll learn
- ✓The four steps: hypothesis, injection, observation and stopping
- ✓Why a steady-state measurement must exist before any injection
- ✓How to run a chaos experiment by reading code and configuration
- ✓Which failures apply to a single-server Rails application
- ✓Blast radius controls and why one container cannot use them
- ✓The order of preconditions: restore, observability, reasoning, staging, production
Chaos engineering is not breaking things
The name is unhelpful. Chaos engineering isn't randomly killing processes to see what happens. It's a method with a specific shape, and the shape is what makes it useful instead of reckless.
Read the full lesson free →Curriculum
7 lessonsChaos engineering is not breaking things
Chaos engineering follows four steps, starting with a measurable hypothesis, and discovers failures that testing never specified.
You cannot do this blind
Observing steady state is the prerequisite, and the available logs need a steady-state number built from them.
The experiment you can run on paper
Tracing the /up health check shows it returns 200 with Postgres unreachable while kamal-proxy keeps routing.
The failures worth injecting here
The failure list comes from this architecture: database loss, full disk, hung jobs, memory exhaustion and half-succeeded deploys.
Blast radius
Traffic fraction, scope, time and abort controls limit blast radius, and one container leaves staging as the option.
What to do before any of this
A tested restore comes first, then observability, reasoned experiments, staging, and production only if redundancy ever exists.
Putting it together
A recap of the course and a challenge to implement evaluate_experiment, where the abort check takes precedence.