Better Software Development Systems through Stress
summary
Argument that deliberately injecting faults builds measurable confidence in availability, not chaos for its own sake. Practical recipe: raise observability, form a small chaos team (<10 people, often <5), design hypotheses and blast radius limits, automate repeat experiments and run them in production when safe. Tools and practices named include Chaos Toolkit, canary metrics and SRE availability math, game days for sociotechnical learning, and reframing as limited scope continuous disaster recovery.
AI-written summary · about
chapters (12)
- 0:00Intro
- 7:20Who am I
- 11:06Chaos
- 14:31Failure
- 17:20Availability
- 19:05Sociotechnical System
- 23:20Chaos Engineering
- 24:55Confidence in Availability
- 25:40How to do Chaos Engineering
- 30:06Chaos Engineering Effects
- 32:32Chaos Testing
- 39:07Chaos Toolkit
related talks
48mHarnessing Chaos; the hidden ingredient behind building better systems
26mBreaking Systems for Resilience
38mWhy software developers should build a resilience culture based on chaos engineering
01h 04mTrust and Confidence through Chaos
44mDeveloping a Culture of Reliability and Resilience through Chaos
01h 04mHarnessing Chaos; the hidden ingredient behind building better systems through learning
29mThe Psychology of Chaos Engineering
21mThe Psychology of Chaos Engineering