Chaos Engineering

Chapter 14. Open Minds, Open Science, and Open Chaos

Russ Miles

Chaos Engineering is science. You seek evidence of system weaknesses that are hidden in the essential complexities of modern, rapidly evolving systems. This is done through empirical experiments that inject controlled but turbulent conditions into a combination of your infrastructure, platforms, applications, and even your people, processes, and practices.

Like all science, Chaos Engineering is at its most valuable when it is highly collaborative: where everyone can see what experiments are being pursued, when they are happening, and what findings have surfaced. But, like science, this can all collapse like a house of cards if the collaborative nature is in any way stymied.

Collaborative Mindsets

Imagine two mindsets. In the first, engineers think along the following lines: “I just like to find weaknesses. I can’t wait to take everyone’s systems and inject all sorts of interesting harm on them to show everyone why they should be improving their systems.”

A team with this mindset is focused on doing chaos to other people’s systems. The goal is still to learn, but this is easily lost in the conflict-style relationship that is likely to be established when the Chaos Team starts to run experiments against other people’s systems. That’s the key problem—it is done to other people’s systems. This team’s remit tends to end with “Here’s the problem!” and even if it goes as far as “Here are some potential solutions,” it’s ...