IGNITE: Metrics, Margins, Mutiny – How to make your SREs (not) run away
summary
SREs come from Google origins and treat reliability as measurable outcomes: define SIs (few, user‑centric metrics), set SLOs with clear aggregation and regions, and spend engineering time on tooling not just ops. Claim: SREs must spend 50% engineering time. On‑call is unavoidable lower bound of toil; Google targets two incidents per on‑call shift. Reduce toil by building highly automatic systems, distribute recurring tasks evenly, and use tools like Kubernetes Anible Prometheus giops engines.
AI-written summary · about
related talks
41mAn Introduction to SRE at Google (with DevOps Focus)
26mFrom Nothing to SRE: Practical Guidance on Implementing SRE in Smaller Organisations
25mSRE Guiding Principles & Transformational Framework
35mCare and Feeding of SRE
31mConfessions of an SRE Manager
38m"Disorganizing" Your SRE Organization
25mPitching SRE to your Senior Executives
49mWhat SRE Could Be: Systems Reliability Engineering