Fireside Chat with Jason Yee
summary
Chaos engineering advocates deliberately controlled failures to validate hypotheses about reliability not to cause harm: a lightning-strike outage reveals a non‑distributed dependency, monitoring dashboards must be exercised, and start in dev and staging before production. Developers increasingly own experiments, basic checks prove alerts and auto‑restart behavior, and frequent manual runs turn into automate chaos in CD pipeline tests. Emphasis is on testing assumptions not breaking for fun and on replaying incidents to train people.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 0:22Why break systems on purpose
- 2:05Practicing failure like a team
- 3:10Testing unplanned assumptions
- 4:54Hypothesis driven chaos
- 6:39Learning from real outages
- 7:40Starting chaos safely
- 8:24Who owns chaos engineering
- 9:48The Chaos Monkey dream job
- 10:51Simple chaos experiments first
- 11:55Reliability vs resilience
- 12:38Chaos for systems and people
- 13:42Why organize conferences
- 16:30Logistics of chocolate
- 17:11Automating chaos tests
related talks
48mChaos Engineering: The Path to Reliability
18mChaos Engineering: Break It On Purpose
27mChaos Engineering: The Path to Reliability
29mThe Psychology of Chaos Engineering
01h 02mPractical Chaos Engineering breaking things on purpose to make them more resilient against failure
49mSpeaker Panel - Day 1
38mWhy software developers should build a resilience culture based on chaos engineering
38mChaos Engineering