Resilience Engineering Mythbusting
summary
Claims that matter: servers can't be resilient because resilience requires human decision making, not just redundancy; the talk separates resilience, reliability and robustness and shows when to use postincident retros, chaos experiments and SLIs/SLOs. Concrete cautions: error budgets do not measure change risk, MTTR/MTBF lie, and root‑cause and Five Whys produce shallow answers. Uses real examples (Meltdown class vulnerabilities, static asset 404 cascade) to argue for contributing factors and more inquiry‑based learning.
AI-written summary · about
chapters (17)
- 0:00Start
- 3:31Myth Myth Number One We'Re Building Resilience into Our Software and Server Architecture
- 5:01Reliability
- 8:01Myth Number Two Complexity Is the Enemy of a Well-Maintained System
- 12:27Myth Number Four Always Follow Best Practices To Ensure System Availability
- 16:10Five Effective Retrospectives Require Aximal Follow-Up Items
- 20:26Problem with Calling Something a Root Cause
- 23:11Myth Number Seven the Frequency and Severity of Incidents Are Good Indicators of How Safe We Are
- 27:55Myth Number Eight Our Worst Incidents Produce the Greatest Learning Experiences
- 28:36Severity Is Not Correlated with Learning
- 30:20Myth Number Nine Error Budgets Can Be Used To Control Risk
- 35:51The Field of Resilience Engineering Is Representative for the Study of Human Factors
- 38:40What Does It Mean To Learn
- 39:40How Do We Know We'Re Learning after a Retrospective African Incident
- 40:35Takeaways
- 40:51How Complex Systems Fail
- 41:07Edo Principle
