Now that you’ve seen the value of Gremlin and Chaos Engineering first-hand, how do you get buy-in from your teammates and leadership?
When presenting Chaos Engineering to your organization, start by framing it in terms of how it will help meet organizational goals. Think about the technical goals your organization is trying to achieve, such as:
For the business side of the organization (i.e. leadership), demonstrate how these goals contribute to higher-level business objectives, such as:
If you can create a clear link between Chaos Engineering and business objectives, you’re much more likely to sell leadership on the value of Gremlin. To learn more about demonstrating this value, check out our Playbook on How to Convince Your Organization to Adopt Chaos Engineering.
Once you’ve gotten comfortable running ad-hoc chaos experiments on your own services and among your own team, try introducing other teams within your organization to the practice. Remember to start small, then gradually scale up:
This isn’t a strictly linear route, either. You may run a CPU experiment on a single service in production, but then run a low-magnitude CPU experiment on another service in testing or staging. Remember not to rush: Chaos Engineering is a way of learning more about your systems and building resilience over time. Run experiments, record your observations, and share your thoughts not just among your own team, but with the entire engineering organization. If an experiment goes wrong, just hit the big red halt button to stop the attack and record your thoughts. There’s no wrong way to run an experiment using Gremlin.