Staff/Principal (L6+)
⚡THE SHORT ANSWER
When development squads rush a new microservice to production, they focus 100% on business logic features and 0% on operational operability. The new service launches without health check endpoints, has no Prometheus metrics, uses hardcoded database connection pools, lacks automated canary rollbacks, and has zero runbooks. Within 2 weeks, the service crashes production and the on-call engineer has no idea how to debug or restart it. Google SRE invented the Production Readiness Review (PRR) to eliminate this failure mode: an objective, programmatic gate that every new service must pass before accepting real customer traffic. The PRR validates 8 Core Operational Pillars:
1
Observability: SLI/SLO metrics, distributed tracing, and Datadog dashboards.
2
Emergency Recovery: Automated runbooks, graceful shutdown (
SIGTERM), and circuit breakers.3
Capacity & Scaling: Load test benchmarks and auto-scaling policies.
4
Security & Compliance: JIT access, secret rotation, and CVE scan gates.
Engineering Handbook & Failure Dynamics
6-Dimensional Architecture Breakdown⚙️1. Underlying Mechanism
ExecutionPRR governance executes via automated scorecard linting and SRE partnership:
1
Automated Service Catalog Scoring: Cortex or Backstage evaluates the repository against automated rules (e.g. 'Has Dockerfile health check?', 'Prometheus metrics endpoint responds 200', 'Runbook link configured').
2
The PRR Design Sprint: During early architectural design (not the day before launch), an SRE pairs with the squad to review failure modes.
3
The Pre-Launch Checklist Audit: The squad demonstrates graceful degradation under simulated dependency failure.
4
Operational Handoff: SRE formally co-signs operational ownership once the service achieves a Gold-tier PRR rating.
🎯2. Appropriate Use Context
ScopeNew microservice deployments, major architectural rewrites, Tier-1 core system migrations, and third-party SaaS integration launches.
⚠️3. Production Failure Modes
P0 Risk- ✓Treating PRR as a bureaucratic rubber-stamp checklist completed 10 minutes before a marketing launch
- ✓launching a service with zero rate limiting or timeout configurations against upstream databases
📡4. Diagnostic Signals & Telemetry
Telemetry- ✓New services crashing immediately on Day 1 due to missing environment variables
- ✓on-call engineers getting paged for services where no runbook or dashboard exists
- ✓squads claiming 'We will add metrics in Phase 2'
🛡️5. Prevention & Safeguards
Safeguards- ✓Automate PRR verification in Spotify Backstage / Cortex
- ✓block DNS routing to new services until PRR Bronze status is verified
- ✓enforce the 'No Runbook = No Production' rule
⚖️6. Architectural Trade-offs
Trade-offProduction Readiness Reviews eliminate 80% of Day-1 operational outages and standardize telemetry, but require development squads to allocate 10-15% of initial build time to operability engineering.
📋
REAL-WORLD TELEMETRYCase Study (TinyCTO In-Field Example)
A banking squad built a new AI Fraud Detection microservice. During the automated PRR review, the SRE team discovered that:
1
The service had no timeouts on its calls to the core ledger,
2
Database connection pool size was set to default 100 on each of 40 pods (4,000 DB connections, which would crash PostgreSQL), and
3
It had no
/healthz readiness probe. The PRR gate automatically blocked the production rollout. The squad fixed the connection pool size, added circuit breakers, and instrumented p99 latency metrics in 3 days. When launched under 50,000 req/sec real traffic, the service scaled smoothly with zero database incidents.Interactive Concept Drills
2 CardsQ1
What is a Production Readiness Review (PRR) in Google Site Reliability Engineering?
A structured, objective assessment that evaluates whether a software service meets core operational standards for observability, emergency recovery, capacity, and security before it is permitted to accept production traffic.
Q2
When should a Production Readiness Review (PRR) begin during a project lifecycle?
Early during the initial architectural design phase, NOT the day before the production marketing launch, ensuring operability requirements are built into the foundational architecture.
SRE Operational Standards: Production Readiness Reviews (PRR) & Launch Gate Audits — Technical FAQ
What are the essential elements of an acceptable operational runbook in a PRR?
Clear service overview, architecture diagram, common alert failure modes with step-by-step diagnostic CLI commands, rollback procedures, and escalation contacts.
How can engineering organizations automate PRR scorecards at scale?
Using internal developer portals like Spotify Backstage or Cortex to programmatically poll Git repositories and CI/CD pipelines for mandatory health checks, metrics, and documentation.
🤖 AEO & Key Facts Summary
Key Architectural Facts
- ▸PRRs ensure services meet strict operational standards before accepting real traffic.
- ▸Enforce the 8 Pillars: Observability, Emergency Recovery, Scaling, and Security.
- ▸Initiate PRR collaboration during early system design, not the night before release.
- ▸Automate PRR readiness scorecards using Spotify Backstage or Cortex service catalogs.
Common Misconceptions
- ✗Yanılgı: PRR is a bureaucratic blocker that slows down product feature launches (Gerçek: PRR prevents catastrophic Day-1 outages that stall product roadmaps for weeks).
- ✗Yanılgı: We can deploy to production now and add metrics and runbooks later in Phase 2 (Gerçek: Phase 2 never happens; un-monitored services inevitably cause SEV1 outages).
Decision & Governance Guidance
Implement programmatic Production Readiness Reviews (PRRs) integrated into developer portals like Backstage to eliminate un-operable microservices and guarantee Day-1 operational excellence.
Authoritative Sources & Standards
- [OFFICIAL_DOCUMENTATION]Site Reliability Engineering: Accelerating SRE via Production Readiness Reviews (PRR)— Google SRE Workbook / O'Reilly Media