SLOwly Burning Out - Avoiding Common Pitfalls When Setting SLOs
summary
Managed OpenShift clusters generate about 7.5 pages per hour during the incident, largely from noisy node-down alerts caused by customer-initiated autoscaling and edge-case misconfigurations. The team removes alerts they cannot control, rolls back impossible SLOs, and fights bureaucratic approval processes using Google SRE guidance and the Westrum culture framework. An internal meta SLO of 3 pages/hour becomes the health target; progress reduces burnout and clarifies which customer-facing SLOs truly matter.
AI-written summary · about
chapters (11)
- 0:00Introduction and speaker intro
- 1:19What is an SLO
- 3:06Why SLOs matter in DevOps
- 7:04Customer behavior challenges with SLOs
- 8:52The boiling frog burnout effect
- 12:54Impact of burnout on team
- 15:06Pitfall one impossible SLOs
- 16:53Pitfall two SLO bureaucracy
- 20:34Pitfall three ignoring well-being
- 22:45Key takeaways and lessons learned
- 24:53Q&A
related talks
43mSLO Burn—Reducing Alert Fatigue and Maintenance Cost in Systems of Any Size
31mServerless Observability: a case study of SLOs
25mAn SLO-Driven Approach to Enhance Kubernetes Cluster Reliability
33mHow and why we lowered our SLO
33mTackling Alert Fatigue with SLOs
23mGoing from 30 to 30 Million SLOs
41mA Theory and Practice of Alerting with Service Level Objectives
47mCultivating Production Excellence