What Google’s SRE Secrets Reveal About Modern Operations and SLOs

SRE Overview

Site Reliability Engineering (SRE) originated at Google as a way for software engineers to tackle complex operations problems. The author reflects on reading the book “SRE Google运维解密”, sharing key takeaways and personal thoughts.

Google’s Infrastructure "Muscle"

Google’s infrastructure is described as the muscle that powers its services, enabling high performance and reliability.

Network : Built on a custom Clos switch architecture using SDN to provide massive bandwidth and dynamic bandwidth management across data centers.

Scheduling System : Borg handles cluster‑level task orchestration and workload scheduling.

Storage : A simple, reliable cluster storage service built on physical disks.

Distributed Lock (Chubby) : Provides a cross‑datacenter lock service for coordinated operations.

Monitoring & Alerting : Borgmon collects metrics for alerts and storage, with an open‑source counterpart in Prometheus.

RPC : Google services communicate via RPC called Stubby (open‑source implementation gRPC) using Protobuf for data serialization.

GSLB and BNS : Global load balancing using DNS, user‑level load balancing, and RPC‑level load balancing to direct traffic to healthy services.

Rethinking Failures

The author argues that failures are inevitable and should not be feared. SRE introduces Service Level Objectives (SLOs) to set realistic quality targets, acknowledging that 100% uptime is impossible. SLOs help teams accept a certain level of failure while keeping it within acceptable bounds.

SLO Benefits

Balancing Cost and Benefit : Increasing availability (adding more 9s) incurs exponentially higher costs; SLOs help find the optimal trade‑off.

Scientific Operations : SLOs provide quantifiable standards for operations, allowing engineers to focus on higher‑value work instead of constantly firefighting.

Stability vs. Innovation : By setting appropriate SLO levels, teams can safely introduce frequent changes for innovation while maintaining acceptable reliability.

Conclusion

The book offers deep insights into Google’s SRE practices and the powerful infrastructure that supports them. While the concepts are valuable, organizations should adapt them thoughtfully to their own context rather than treating them as a universal cure‑all.