SRE cannot support every service at Google; there are far more services than SREs. This chapter describes how SRE decides what to take on and how it has changed the model over time so that its influence scales. The production readiness review is the gate; the frameworks model is the way SRE scaled past the gate by baking its standards into the libraries developers use.

The chapter is useful for understanding what "SRE support" actually means and why it is a negotiation, not an entitlement.

In one minute

• SRE's goal in engaging with a service is to improve its reliability through its whole lifecycle. The default state is that a developer team runs its own service, and SRE engagement is a deliberate decision.
• The production readiness review (PRR) is the standard entry point. SRE assesses a service against a checklist of production standards, identifies gaps, and the development team fixes them before SRE takes the pager. The PRR also checks that the service is important enough and has a reasonable operational load.
• The simple PRR model: engagement is requested, SREs analyse the service (architecture, dependencies, capacity, monitoring, release process, incident handling), produce a list of improvements, work with developers on them, then train and take over on-call. This can take months and is done per service.
• Problems with the simple model: it happens late, when the design is fixed and changes are expensive; it is slow; it does not scale, because every service is reviewed from scratch; and the services that most need help are often the ones nobody has had time to review.
• Early engagement model: SRE joins during design, before any code, for services that are expected to be important. SRE influences the architecture, the service is built on standard infrastructure from the start, and the PRR at launch is short.
• Frameworks and the SRE platform: SRE and developers build frameworks per language that include the production features SRE requires (standard monitoring, RPC handling, logging, configuration, graceful shutdown, load shedding). A service built on the framework is production-ready by construction.
• Benefits: lower operational cost per service, SRE can support many services, developers get reliability without redoing it, and the frameworks become where SRE's engineering effort goes.
• New engagement model: a shared SRE team supports many framework-based services, with a lightweight PRR, and the development team keeps more responsibility. Incentives shift toward using the standard platform.

SRE engagement: what, how, and why

SRE teams engage with a service to make it more reliable, by setting SLOs and error budgets, improving monitoring, reviewing architecture, and taking on-call. Not every service qualifies. SRE looks for services that are important to the business, that have a reasonable operational load, that will benefit from SRE involvement, and whose developers are willing to work on reliability. A service that fails these tests stays with its developers, who still get SRE consultation.

The PRR model

The PRR is a structured review. SREs read the design, inspect the production deployment, examine the monitoring and alerting, check the release process and the capacity plan, and look at past incidents. The output is a list of gaps against SRE's standards: missing SLOs, no canaries, single points of failure, missing playbooks. The developers fix them, often with SRE help. When the gaps are closed, SRE takes on-call, usually after a period where the two teams share it. The PRR is also where the service's SLO, error budget and on-call expectations are agreed in writing.

The simple PRR model

The flow is engagement request, analysis, improvements and refactoring, training, on-boarding, continuous improvement. It works, but it is expensive and it comes too late. Changing a service's architecture after launch is hard, and in the meantime SRE is often brought in only when the service is already in trouble. Each review is bespoke, so SRE capacity bounds the number of services it can support. And the model treats SRE as a reviewer, when SRE's most valuable contribution is to the design.

Evolving the simple PRR model: early engagement

For services that are known in advance to be important, SRE engages at the design phase. An SRE participates in design reviews and in choosing infrastructure, so the service is born on standard building blocks with standard monitoring. The PRR at launch is then mostly confirmation. Early engagement also lets SRE help with the launch itself and with capacity planning before traffic arrives. The drawback is that it ties up SRE time on a service that might not matter, so it is reserved for products with clear business importance.

Evolving services development: frameworks and SRE platform

The scalable answer is to put SRE's standards into code. Google built frameworks, per language, that implement the production features every service needs: instrumentation for the standard monitoring system, structured logging, RPC with deadlines and criticality, configuration handling, health checks and lame duck, load shedding, and standard dashboards and alerts. A service built on the framework inherits all of it, so the PRR checklist is mostly satisfied by construction.

Developers get a faster path to production and a service that behaves well without each team reinventing reliability. SRE gets services that look alike, so a shared SRE team can support many of them and the on-call knowledge transfers. Frameworks also give SRE a lever: improving the framework improves every service built on it, which is the highest-leverage engineering an SRE team can do.

New service and management benefits. With frameworks in place, SRE introduced a lightweight PRR for framework-based services, a shared production platform SRE team, and a model where development teams keep more operational responsibility with SRE as a resource. This shifted incentives: using the standard stack became the path of least resistance, and services that chose to be non-standard had to justify why and bear the cost.

Conclusion

The engagement model moved from reviewing services one by one to building the platform that makes services reviewable in minutes. This is the organisational version of the automation principle in chapter 7: the end state is a system that does not need the manual process at all.