Creating Foresight

In one line

You think the value of a chaos experiment lies in what you see when the fault is injected. In fact much of it comes before: gathering engineers to design the experiment forces each of them to state what they expect the system to do. The disagreements, and the questions nobody can answer, are the blind spots in their mental models. The chapter recasts chaos engineering from a tool for learning after the fact into a tool for creating foresight: imagining the incident before it happens.

Glossary

Where it sits

Chapter 9 of the book, by Andy Fleener, opens Part III, "Human Factors". The five company chapters of Part II were about how to run experiments. From here on the focus moves from the machines to the picture in people's heads, leading into Ch10 Humanistic Chaos and Ch11 People in the Loop. The title is shared with a paper by resilience-engineering researcher David Woods on the Columbia shuttle accident, and the idea is the same: safety comes from imagining ahead, not from assigning causes afterwards. In practice it speaks to any team that runs plenty of postmortems yet keeps having the same incidents.

The problem this chapter tackles

Take a typical setup: an ordering service depends on a cache, a database, a payment gateway and a message queue. Four or five teams own one piece each and ship dozens of times a week. When something breaks, the postmortem is the first time anyone puts all their understandings side by side: "oh, so it keeps retrying once the connection pool is full", "oh, nobody has been subscribed to that alert for months."

Learning this way has two structural problems. It's expensive: every lesson is bought with a real incident, and users have already paid. It's contaminated by hindsight: knowing the ending, people line up a string of signals that were ambiguous at the time into an "obvious" causal chain, then ask why nobody saw it. Reviews drift into blame and people start saying less.

Chaos experiments could move that learning to before the incident. But many teams treat them as "install a tool, kill random machines". Nobody states an expectation up front, so the result is "seems fine" and nothing is learned. Or the experiment causes a real incident, and it turns out nobody could have said what the system would do in the first place.

So the question here is: how do you use chaos engineering to create foresight, digging out the disagreements and blind spots in engineers' mental models before an incident does it for you?

The core ideas, explained

1. The chaos cycle has three phases, and "before" is the most underrated

The chapter splits an experiment into before (design), during (injection and observation) and after (analysis and learning). Tool vendors and most discussions concentrate on "during": how to inject, how to limit the blast radius, how to abort with one click. Fleener argues that the "before" phase produces a great deal of insight on its own, and it decides what you look at during the experiment and what you can learn afterwards.

The intuition is simple. Injection is just a button, but to press it a group of people first has to answer "what do we expect to happen?" Once that question is asked seriously, many answers arrive before the button is pressed: an alert that was never configured, or two senior engineers predicting opposite outcomes for the same path.

2. Chaos engineering serves resilience's ability to anticipate

The chapter borrows a framework from resilience-engineering researcher Erik Hollnagel. A system shows resilience through four abilities: respond (handle what happens), monitor (know what to watch), learn (improve from experience) and anticipate (imagine what might happen).

Traditional reliability work mostly shores up the first three. Alerts cover monitoring, on-call and runbooks cover response, postmortems cover learning. Anticipation is the hardest to practise, because it asks people to think about something that hasn't happened yet. Designing a chaos experiment gives it a structured practice ground. "What happens if this dependency slows down by 2 seconds?" is, in effect, a review of an incident that hasn't happened yet.

3. Mental models: everyone is touching a different part of the elephant

Part I set up the premise: complex systems are too large for any one person to hold. Each engineer carries a partial model. The application engineer knows the retry logic, the database engineer knows the connection limits, the platform engineer knows how nodes get scheduled. These models differ from each other and are each out of date.

The design session puts those models on the same table. It digs out two kinds of finding:

• Disagreements: two people predict opposite outcomes for the same thing. "If the cache dies, orders get slower but don't fail" versus "if the cache dies, the database connection pool fills up within tens of seconds." Disagreements are the best places to experiment, because at least one model is wrong.
• Blind spots: a question gets asked and nobody can answer it. "Who receives this alert?" "What's this service's timeout?" Not knowing is itself the finding, and you can often fix it without injecting anything.

4. Running the design session: a facilitator and four topics

The most practical part of the chapter is how to run this pre-experiment discussion. The key role is the facilitator, who is there to ask, follow up and record what each person says, not to supply answers. A good facilitator is often less familiar with the system: an outsider's questions are more likely to poke at things everyone assumes are obvious but nobody has checked.

The discussion covers four topics, roughly in this order:

• Understand operating procedures. Start with "when this happens today, what happens?" Who gets paged? Which dashboard shows it? Where's the runbook, and when was it last used? This exposes the gap between work-as-imagined and work-as-done: the documented process is often not what people actually do.
• Discuss scope. "What exactly are we breaking?" One instance, one availability zone, or a whole dependency? Which users, for how long? Scoping often reveals that people had different things in mind, and it also sets the blast radius.
• Hypothesize. Have each person state (ideally write down first) what they expect: how the steady-state metrics move, which alerts fire, how long recovery takes. The hypothesis must be specific enough to be falsified, e.g. "with 2 seconds of injected latency, order success stays above 99.9% and p99 rises from 300 ms to under 2.5 s." Writing privately before sharing stops the most senior person from steering the whole room the moment they speak.
• Choose tools and partner internally. Tools must control scope precisely, abort at any time and show everyone the same observability data. Affected teams, on-call and customer support need to know in advance.

The quality of the session depends on how questions are asked. Good questions are open and descriptive: "What do you think happens first?" "How would you notice?" "What happened last time?" Bad ones are closed or judgemental: "This should be fine, right?" "Why isn't there a circuit breaker?" The first kind opens up models. The second makes people defend themselves.

5. From "before" back to "after": making foresight a loop

After the run, go back through the hypotheses written in the design session one by one. Which held, which were refuted, whose model needs updating? A refuted hypothesis isn't anyone's failure. It's a lesson that cost no incident. Feed the conclusions into procedures, alerts and architecture changes, then start the next design round. Each turn brings the team's shared picture of the system a little closer to reality.

Key trade-offs and choices

First table: the ways a team can learn how its system fails.

The design session is unusual because it joins imagining to verifying: a tabletop has only the first, raw injection only the second.

Second table: where the facilitator comes from.

Concrete choices:

• Team new to chaos: don't rush to tooling. Pick a critical path that recently had an incident, hold one design session and run a single experiment. The first payoff usually comes in the meeting.
• Everyone agrees and is confident: that experiment probably carries little information. Spend the effort where people disagree or nobody can answer.
• The session finds a blind spot (e.g. an alert nobody receives): fix first, then experiment. Injecting a fault to demonstrate a known defect is paying to prove what you already know.

Why it matters / in real systems

Three lines to take into a design review. One: chaos engineering produces knowledge, not outages, and the biggest share of that knowledge comes before the experiment. Two: disagreements and unanswerable questions are the best pointers for choosing experiments. Three: a postmortem is learning after you've paid; a design session is learning before you pay.

Asked in an interview "how do you do chaos engineering?": "we use tool X to kill random instances weekly" is one level. "Before every experiment we hold a design session: walk through procedures, agree scope, have everyone write a hypothesis, pick the disagreements to test, then compare results and update the runbooks" is another. The second shows you understand that chaos engineering targets people's understanding of the system, not just the system.

Pitfalls and debates

• Turning the design session into an approval meeting. If its purpose is "confirm the experiment is safe and sign off", people only say what gets the experiment approved, and disagreements are suppressed. Safety checks matter, but they can't replace "what do you expect to happen?"
• Seniors speak first. Once the most experienced person states an expectation, others nod along and disagreements vanish. Have people write privately, then reveal together.
• Recording conclusions but not expectations. Without hypotheses written beforehand, everyone feels afterwards that they "knew it all along". Hindsight bias applies to experiments too.
• Experimenting for its own sake. Fix defects the session already found. Testing a scenario whose outcome everyone is sure of yields little information.
• Foresight isn't prediction. A design session can't guarantee you think of every failure mode; complex systems always have combinations nobody imagined. Its value is making the team better at imagining and noticing, not producing a complete list. Ch12's lineage-driven fault injection attacks the "nobody thought of it" gap from the other direction.
• Limits of the era, and debate. The chapter reads as a practitioner's distillation, argued from cases and resilience-engineering literature, with no quantitative evidence of how much design sessions reduce incidents. Their cost (many people, several hours) is often cut in fast-moving teams. Still, it pulls chaos engineering back from "tooling" towards "learning" and sets the tone for the human-factors chapters that follow.

Key takeaways