The complexity in modern and distributed architectures continues to increase. We have successfully broken down our application into small and maintainable components. Each individual component can be automated and brought into production at any time. A lot of effort was put into the development to keep the test coverage as high as possible. Every release has to successfully pass our pipeline and countless unit, integration and acceptance tests. But why do we have this unpleasant feeling shortly before our arrival at the most beautiful place in the world (production)? Many open questions cannot be answered by simple unit or integration tests. This is where Chaos Engineering comes in. It helps us to become master of chaos and please do not claim that you are not in chaos! There is a whole industry that sells us ticket systems with which we can document chaos. In this talk you will learn how to introduce Chaos Engineering. Using practical examples, you will learn what can go wrong. At the end of the talk we will conduct a Chaos Experiment in a distributed application. With the help of the Chaos Monkey for Spring Boot we will try to crash the application. But thanks to the implemented Resilience Pattern this won’t work.