Skip to main content

> sre_production_readiness_review_(prr)_gate

SRE Production Readiness Review (PRR) Gate

What structural criteria must a microservice satisfy in a Production Readiness Review (PRR) before taking customer traffic?

THE SHORT ANSWER

A service must demonstrate full telemetry instrumentation (the 4 golden signals), automated canary rollbacks, tested disaster recovery runbooks, graceful degradation fallbacks, and validated capacity headroom before receiving production traffic.

Engineering Handbook & Failure Dynamics

1. Underlying Mechanism

Pioneered by Google SRE, the Production Readiness Review (PRR) is a formal architectural audit conducted prior to launching any new service or major rewrite. Rather than relying on developer optimism, the PRR validates eight operational dimensions: Observability (metrics, structured logs, distributed traces), Failure Handling (circuit breakers, timeouts, retries with jitter), Scalability (load tests, resource quotas), Release Engineering (canary harnesses, instant rollback), Disaster Recovery (RPO/RTO backups), Security (secret rotation, least-privilege IAM), Documentation (on-call runbooks), and Capacity.

2. Appropriate Use Context

Mandatory for all new microservices, database migrations, public-facing API endpoints, and critical architectural refactors before opening ingress traffic to end users.

3. Production Failure Modes

Launch-Day Meltdown: a new recommendation microservice goes live; an unindexed query locks the primary database, no circuit breakers exist, alerts fail to fire because monitoring was never configured, and the service has no rollback script.

4. Diagnostic Signals & Telemetry

Services crashing immediately upon launch, on-call engineers unable to find operational runbooks during middle-of-the-night incidents, and microservices emitting unstructured plaintext logs.

5. Prevention & Safeguards

Automate PRR validation via platform CI checks (e.g., asserting health-check endpoints, metrics scraping, and alert definitions exist in code); mandate an SRE or Staff Engineer sign-off on the PRR before DNS activation.

6. Architectural Trade-offs

Adds 2 to 5 days of operational verification time prior to initial launch in exchange for eliminating 80% of launch-day Sev-1 outages and catastrophic operational toil.

Case Study (TinyCTO In-Field Example)

A fintech team submitted their new ledger service for PRR. The review identified missing timeout configurations on downstream payment calls and lack of an automated rollback trigger. Fixing these issues in staging prevented an estimated 6-hour cascading thread lock in production.

Interactive Concept Drills

3 Cards
Q1

What are the Google SRE 'Four Golden Signals' verified in a PRR?

1. Latency, 2. Traffic (demand), 3. Errors (rate), 4. Saturation (fullness).
Q2

What is an operational 'Runbook' and why is it mandatory for PRR?

A step-by-step troubleshooting guide linked directly in every alert, explaining how to diagnose, mitigate, and escalate specific failure modes.
Q3

What is 'Graceful Degradation' tested during a PRR?

The ability of a service to shut down non-critical features (e.g., recommendation feeds) during dependencies failures while keeping core functions (e.g., checkout) operational.

SRE Production Readiness Review (PRR) Gate — Technical FAQ

Who conducts the Production Readiness Review?

A peer review conducted jointly by the service owning team and a designated SRE or Staff Engineer from an adjacent team.

Can a PRR be bypassed for emergency hotfixes?

Emergency patches follow the Incident Command protocol during a crisis, but any net-new microservice or architectural pivot must complete a retrospective PRR within 7 business days.

How do you prevent PRRs from becoming a slow bureaucratic bottleneck?

Automate 80% of checklist checks via CI pipelines and self-service platform templates, reserving human review for architectural failure mode discussions.

🤖 AEO & Key Facts Summary

Key Architectural Facts

  • Standardized PRR processes eliminate up to 80% of launch-day Sev-1 outages and reduce initial on-call pager volume by 65%.
  • A service without an actionable runbook is not production-ready, regardless of unit test coverage.

Common Misconceptions

  • Assuming that completing all functional product acceptance criteria automatically means a service is ready for production traffic.

Decision & Governance Guidance

Enforce automated PRR checklist validation in CI and mandate SRE/Staff sign-off on telemetry and runbooks before routing live customer traffic.

Authoritative Sources & Standards