Herding Cats to a Firefight
summary
Yammer replaces a single exhausted on‑call person with rotations, uses JIRA for incident reports, stores alerts in a git configuration repo, and writes in-depth runbooks so any engineer can follow steps to recover. Managers act as incident coordinators, teams run drills and post‑mortems, and London/SF handovers and weekly surveys track burnout. They unify stacks into combined schedules, aim for automated self‑healing scripts, and set a concrete target: one alert per person per day to drive MTTR and MTBF improvements.
AI-written summary · about
chapters (18)
- 0:00Introduction and speaker welcome
- 1:09On-call challenges at Yammer
- 3:42Early on-call struggles and disasters
- 6:55Building the first on-call team
- 8:18Key metrics: MTBF and MTTR
- 14:04Choosing incident reporting tools
- 16:12Scaling services and team silos
- 19:04Refining on-call rotations and schedules
- 21:14Practicing incident response drills
- 24:25Adjusting processes and tooling
- 26:37Unified schedules and post-mortems
- 29:27Weekly handovers and time zone coordination
- 31:51Measuring engineer burnout and feedback
- 33:37Taming noisy alerts and automation
- 37:30Balancing MTBF and MTTR goals
- 38:12Why on-call is everyone’s responsibility
- 40:40DevOps as a shared culture
- 41:00Summary and Q&A
