I started to build FireHydrant, because the solutions for incident management were just bad (to put it nicely). My goal is to build tech for engineers, by engineers. So, I incorporated my experiences, and feedback from the community, to implement researched and vetted recommended practices into an incident management platform. The chaos engineering I'm speaking to is from actual experiences that I and my team have had and we want to make sure other engineers can focus on building without BS.
We’re pretty sure using a real incident to test a new response process is not the best idea. So, how do you test your process ahead of time?
This talk will share how to leverage best practices to break, mitigate, resolve, and fireproof incident processes. We’ll show you how to use chaos engineering philosophies to stress test 3 critical parts of a great process:
1. When and how you declare an incident
2. How you communicate an incident - internally and externally
3. When and if you should escalate an incident to your stakeholders
Priority access to all content
Exclusive promotions and giveaways