You Should Be On Call, too
summary
Claims that developers standing primary on‑call reduce mean time to repair and create a collaborative culture; multiple companies (opscode, Heroku, Etsy, Sourcefire, custom Inc) try it and some revert, but reports show fewer ops burnouts because Nagios and PagerDuty surface actionable alerts when developers add instrumentation. Teams build deployment and ops tooling like private Chef cuddle around Hosted/Private Chef and rely on Chef automation and codahale/ruby metrics. Result: application defects get fixed faster and tests added, operational knowledge spreads because there are more developers than sysadmins.
AI-written summary · about
chapters (12)
- 0:00Intro
- 1:06% whoami
- 2:55Who are you? (Show of hands)
- 8:10A typical problem...
- 10:57Companies Studied
- 12:57Overall Results
- 17:26Show of hands, do you...
- 18:17Instrumentation
- 19:53Opscode builds tools
- 22:10Building tools
- 22:39If you're a consultant...
- 24:46Take aways
related talks
50mYou build it, you run it (why developers should also be on call)
44mYou build it, you run it
31mHow to Build a Healthy On-call Culture
24mWait for Us! Evolving On-Call as Your Company Grows
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
23mFirefighting: The Engineer's Guide to On-Call