Breaking Systems for Resilience
summary
Empirical claim: adopting chaos engineering raises availability (47% in a Gremlin survey) while lowering MTTR (45%) and MTD (41%); 63% of practitioners ran experiments and 30% run them in production. Practical workflow: define steady state, build a failure model, limit blast radius, inject failures, monitor and run post‑incident analysis. Tools cited: LitmusChaos, Chaos Monkey, Chaos Blade, Chaos Mesh, Chaos Toolkit, STO. Examples: design a CRUD microservice with DB replication, cache and three AZ replicas, then run chaos game days and automated experiments in CI/CD to measure resilience.
AI-written summary · about
chapters (14)
- 0:00intro
- 0:22preamble
- 0:56hello, dhiraj here
- 1:32what is chaos engineering
- 2:15why is it important for developers?
- 4:23what is the biggest inhibitor to adopting/expanding chaos engineering?
- 7:35what are different modes of chaos experimentation?
- 11:28few of the popular open source tools used for chaos engineering
- 12:28think chaos while software development
- 13:55how to run controlled experiments?
- 16:08design a micro-service responsible for doing some crud operations and basic computations?
- 20:46best practices in chaos engineering
- 23:36chaos engineering today
- 25:24thanks
related talks
18mChaos Engineering: Break It On Purpose
27mChaos Engineering: The Path to Reliability
48mChaos Engineering: The Path to Reliability
21mThe Psychology of Chaos Engineering
29mThe Psychology of Chaos Engineering
37mChaos Engineering: The Fine Art of Breaking Stuff in Production on Purpose
33mChaos Engineering, how to increase resilience by injecting chaos
29mPractical distributed systems: Building for the real world with chaos engineering