Practical Chaos Engineering breaking things on purpose to make them more resilient against failure
summary
Claims that controlled failure injections reveal real weaknesses and advocates starting small: local Docker Compose apps (example project “Eleanor”) and 1% canary traffic before production. Recommends measuring steady state with business metrics (orders/minute), testing people dependency by removing a key engineer, and limiting blast radius with an emergency stop. Demos include chaos toolkit, Gremlin and toxic-proxy, Linux tools (tc, stress, iptables), RDS/Aurora fault injections and Kubernetes pod killers; shows 100 ms latency cuts orders ~1% and gives concrete rollback and monitoring checks.
AI-written summary · about
chapters (33)
- 0:00Introduction
- 2:02Firefighters
- 3:09Game Days
- 5:06Microservices
- 6:13Netflix
- 8:52People Attack
- 10:54Chaos Engineering
- 12:40Prerequisites
- 12:51Application Resilience
- 16:08Steady State
- 16:57Normal Behavior
- 17:10Output Assist
- 20:07Positive Rights
- 20:26Running the Experiment
- 22:22Verify
- 23:30Detect
- 24:42Postmortems
- 26:32Deep Dive
- 28:28Tools
- 28:43Start simple
- 29:45My code
- 31:05Health check
- 31:59Product ID
- 32:37Case Experiment
- 37:04Rate Limiting
- 37:57Latency
- 39:55Stress
- 41:18DNS
- 41:53Linux tools
- 43:35Chaos Toolkit
- 48:15Grimian
- 49:41Gremlin
- 53:55Toxic Proxy
related talks
18mChaos Engineering: Break It On Purpose
37mChaos Engineering: The Fine Art of Breaking Stuff in Production on Purpose
57mChaos Engineering Primer
39mChaos: Breaking your Systems to Make them Unbreakable
46mDesigning a System for Chaos
38mChaos Engineering
45mThe Glorious Art of Destroying Things on Purpose: an Introduction to Chaos Engineering
48mHarnessing Chaos; the hidden ingredient behind building better systems