Trust and Confidence through Chaos
summary
Argues that running small, hypothesis-driven failure experiments — first in staging, then automated in production — uncovers human, platform and infrastructure faults before customers see them, using tools like Chaos Monkey, Kubernetes control-plane tests, Docker and AWS/Cloud Foundry accounts as attack surfaces. Recommends starting tiny, documenting game days, giving teams observability and shared “skin in the game,” and building a reusable chaos platform. Claims this yields measurable trust and resilience rather than just post-mortems and promotes continuous chaos as part of delivery.
AI-written summary · about
chapters (23)
- 0:00Introduction and welcome
- 22:45Russ Miles introduction
- 28:19Who am I and chaos philosophy
- 31:13Production is a socio-technical system
- 33:45Resilience vs technical robustness
- 36:35Margaret Hamilton and chaos engineering history
- 39:13Murphy's Law and production hates you
- 40:36From complicated to chaotic systems
- 42:47What is chaos engineering
- 44:13Pre-mortems and proactive learning
- 45:43Mindset and process for chaos engineering
- 47:33Hypothesis-driven experiments
- 49:21Starting small and growing scope
- 50:23Automating chaos experiments
- 51:06Ethics and skin in the game
- 52:10Game days and collaborative learning
- 53:36Overcoming skepticism about chaos
- 54:38Chaos Club rules and terminology
- 55:42Chaos experiments should not be surprises
- 57:09Building a chaos platform
- 58:34Chaos engineering as a best practice
- 59:59Resources and next steps
- 1:01:20Q&A and closing
related talks
48mHarnessing Chaos; the hidden ingredient behind building better systems
45mDeveloping a Chaos Architecture Mindset
01h 04mHarnessing Chaos; the hidden ingredient behind building better systems through learning
43mBetter Software Development Systems through Stress
44mDeveloping a Culture of Reliability and Resilience through Chaos
46mEmbracing Collaborative Chaos: Chaos Days on Large Platforms
26mBreaking Systems for Resilience
38mWhy software developers should build a resilience culture based on chaos engineering