A Brief Introduction to Chaos Engineering

Destruction for a positive outcome

There are very few things as satisfying as destruction, especially when we’re frustrated.

How often do you have an issue that you cannot solve and you just want to scream or take a hammer and destroy servers in your datacenter? Or how often do you have a problem in production that is negatively affecting a lot of users, and you are under a lot of pressure to solve it but cannot “crack” it as fast as you should. You have probably experienced this at least once. If something like this has never happened to you, then you have probably never been in a position under a lot of pressure. However, in my case, there have been countless instances when I wanted to destroy things out of frustration. But I didn’t, for quite a few reasons. Destruction rarely solves problems, and it usually leads to negative consequences. I cannot just go and destroy a server and expect that I will not be punished.

The goal of chaos engineering

However, what would you say if I told you that we can be rewarded for destruction, and that we can do a lot of good things by destroying stuff? If you don’t believe me, you will soon. That’s what chaos engineering is all about. It is about destroying, obstructing, and delaying things in our servers and clusters. We’re doing all that, and many other things, to achieve a very positive outcome.

Chaos engineering tries to find the limits of our system. It helps us deduce what the consequences are when bad things happen by trying to simulate the adverse effects in a controlled way. We do this as a way to improve our systems and to make them more resilient and capable of recuperating and resisting harmful or unpredictable events.

That’s our mission. We will try to find ways we can improve our systems based on the knowledge that we obtain through the chaos.

---

The next lesson contains an introduction to the authors.