You build it, you run it
summary
Argues that developers owning production reduces feedback gaps by combining code ownership with monitoring and on‑call practices, backing that with concrete tools and practices: aggregated logs (ELK or Papertrail), alert rotation via PagerDuty or OpsGenie, one‑week on‑call shifts, pairing a newbie with an expert, and blameless postmortems. Proposes an on‑call ABC — assess, blast radius, compensate — and prioritizes mean time to recovery over mean time between failures, citing real incidents (multi‑hour outages) that were fixed and then documented.
AI-written summary · about
chapters (17)
- 0:00Introduction and speaker background
- 3:21Feedback loops in development
- 7:44DevOps on-call evolution
- 12:08ABCs of being on-call
- 17:49Learning from failures and outages
- 21:05Alerting systems and best practices
- 27:08Preventing burnout in on-call
- 31:01Summary and call to action
- 31:46Q&A: Single engineer leaving
- 32:55Q&A: Preventing all failures
- 33:38Q&A: Work-life balance in on-call
- 35:09Q&A: Managing legacy systems
- 36:42Q&A: Ops vs app teams
- 38:41Q&A: Balancing feature work and fixes
- 39:52Q&A: Grooming alerts
- 41:13Q&A: Handling user support queries
- 42:23Q&A: Reducing support footprint
related talks
50mYou build it, you run it (why developers should also be on call)
31mHow to Build a Healthy On-call Culture
27mYou Should Be On Call, too
22mRaise a Production System:Making on-call human-scale w/ Observability & Trust
28mBuilding a healthy on-call culture
29mCalling out a terrible on call system
26mBuild a data-driven on-call workflow for your team with atomic habits
19mIts Time We Rethink On-Call Culture