Resilience engineering mythbusting
summary
Argues that true resilience is about decision‑making and learning—not redundancy—so practical claims: high‑availability, load balancers and caching are resilience ≠ robustness examples that don’t adapt; post‑incident reviews and chaos engineering must build operational expertise, runbooks sometimes require going off‑book, and retrospectives succeed by growing judgment not just listing action items. Warns metrics like days‑since‑SEV1 mislead, cites Meltdown/Specter as hidden‑risk proof, and flags dark debt; asks instead: can it adapt?
AI-written summary · about
chapters (6)
- 0:00Intro
- 1:51We're building resilience into our software and server architecture
- 3:36Complexity is the enemy of a well maintained system
- 4:37Always follow best practices to ensure system availability
- 6:21Effective Retrospectives require actionable follow up items
- 7:46The frequency and severity of incidents are good indicators of how safe we are.
related talks
43mResilience Engineering Mythbusting
30mResilience Engineering Mythbusting
05mWhat is resilience engineering
22mResilience Is Not Enough
06mCan Resilience Engineering be sufficiently described in 5...?
51mWithout Resilience, Nothing Else Matters
58mResilient by Design
16mResilient by Design: Architectures for Crisis Response & Recovery