Chaos Engineering

Part II. Principles in Action

We felt it was important to showcase different voices from different organizations throughout this book. There is no one-size-fits-all Chaos Engineering program. Some of the opinions and guidance presented herein are not entirely consistent, and that’s okay. We did not shy away from disagreement and opposing viewpoints. You will find common themes like building a “big red button” into chaos programs, as well as conflicting opinions like whether Chaos Engineering is a form of testing or experimentation.¹

We specifically chose perspectives from Slack, Google, Microsoft, LinkedIn, and Capital One. We bring forth the most compelling examples and narratives and we leave it to the reader to pick and choose which are most relevant to their own circumstances. In complex systems, context is king.

We begin with Chapter 4, “Slack’s Disasterpiece Theater” with Richard Crowley describing the particular approach to Chaos Engineering at Slack. With a combination of legacy and modern systems, Slack provides a target-rich environment for exploring different methods of Chaos Engineering. Richard chose to develop a unique approach to Game Days with particular flair: “Through more than twenty exercises it has discovered vulnerabilities, proven the safety of systems new and old, and affected the roadmaps of many engineering teams.”

Jason Cahoon takes us inside Google’s analog to Chaos Engineering, called “DiRT,” in Chapter 5, “Google DiRT: Disaster Recovery Testing.” ...