Y2K and Other Disappointing Disasters: How To Create Fizzle
summary
A clear claim: massive prep makes disasters fizzle rather than being overblown, shown by Y2K teams who patched firmware, carted floppies and sat in war rooms instead of a cascade of outages. Concrete tools and failures include paginated on‑call ops and physical upgrades, building codes that saved Torch Tower but not Grenfell, the I‑35W bridge collapse from undersized gusset plates plus added load, and engineering practices like microservices, kill switches and Chaos Monkey with feature flags (LaunchDarkly) to forceable test and degrade gracefully.
AI-written summary · about
chapters (32)
- 0:00Introduction
- 1:31Pages
- 3:14Alarmism
- 3:51Y2K Mitigation
- 5:18Space Program
- 6:12Risk Reduction
- 6:42Essential Elements of Reducing Risk
- 8:02Avoiding Risk
- 8:50Finite State Machines
- 9:44Zip Codes
- 10:42Harm Mitigation
- 11:19Building Codes
- 11:57Mexico City
- 13:56Granville Towers
- 17:10Identifying Risk
- 18:45What is Failure
- 21:41Risk Model
- 22:01Kill Switch
- 22:17Never Deploy
- 22:36Failure is inevitable
- 23:00Why is predicting disasters so complicated
- 23:50Internet magic
- 26:25Minneapolis Bridge
- 29:30General Concepts
- 29:48Things that cause disasters
- 30:41Messaging
- 31:30Storage
- 32:14Test
- 33:09Automate
- 34:57Testing
- 36:18Expect Failure
- 36:45Launch Darkly
related talks
39mY2K and Other Disappointing Disasters: Risk Reduction and Harm..
16mEngineering Failure-Resilient Systems
40mThe History Of Fire Escapes: How To Fail (Keynote)
32mBuilding for Gracious Failure
16mClosing remarks
41m‘Failure’ as Success: The Mindset, the Methods, and the Landmines
10mDesigning for Failure using AWS: Resilient Systems
28mBuilding Resilient DevOps Pipelines: Strategies for Handling Unexpected Failures &...