13 Chaos engineering (for) people

 

This chapter covers

  • Understanding mindset shifts required for effective chaos engineering
  • Getting buy-in from the team and management for doing chaos engineering
  • Applying chaos engineering to teams to make them more reliable

Let’s focus on the other type of resource that’s necessary for any project to succeed: people. In many ways, human beings and the networks we form are more complex, dynamic, and harder to diagnose and debug than the software we write. Talking about chaos engineering without including all that human complexity would therefore be incomplete.

In this chapter, I would like to bring to your attention three facets of chaos engineering meeting human brains:

  • First, we’ll discuss the kind of mindset that is required to be an effective chaos engineer, and why sometimes that shift is hard to make.
  • Second is the hurdle to get buy-in from the people around you. You will see how to communicate clearly the benefits of this approach.
  • Finally, we’ll talk about human teams as distributed systems and how to apply the same chaos engineering approach we did with machines to make teams more resilient.

If that sounds like your idea of fun, we can be friends. First stop: the chaos engineering mindset.

13.1 Chaos engineering mindset

13.1.1 Failure is not a maybe: It will happen

13.1.2 Failing early vs. failing late

13.2 Getting buy-in

13.2.1 Management

13.2.2 Team members

13.2.3 Game days

13.3 Teams as distributed systems

13.3.1 Finding knowledge single points of failure: Staycation

13.3.2 Misinformation and trust within the team: Liar, Liar

13.3.3 Bottlenecks in the team: Life in the Slow Lane

13.3.4 Testing your processes: Inside Job

Summary

13.4 Where to go from here?