I would operationalize production readiness as an evidence-based risk-control system attached to the service lifecycle. Each requirement should have an owner, measurable acceptance criteria, machine-verifiable evidence where possible, and an explicit exception process.

Google’s PRR model evaluates architecture and dependencies, instrumentation, emergency response, capacity, change management, and service performance. It also recommends engaging during design rather than waiting until launch, when structural corrections become expensive. (Google SRE)

1. Classify the system before assessing it#

Apply different requirements based on operational risk. A three- or four-tier model is usually sufficient.

The classification determines:

• Required controls
• Required reviewers
• Test depth
• Approval authority
• Review frequency
• Maximum waiver duration

This prevents a low-risk internal tool from undergoing the same process as a payment system.

2. Define readiness as controls plus evidence#

Do not ask, “Is monitoring configured?” Define the control and the required proof.

SLOs, observability, performance testing, and capacity planning should be explicit parts of operational readiness rather than implicit architectural expectations. (Google Cloud Documentation) Security controls should also be integrated into the development lifecycle instead of operating as a separate pre-release inspection; this is the model used by NIST’s Secure Software Development Framework. (NIST Computer Security Resource Center)

3. Separate hard gates from maturity scoring#

A total score alone is unsafe because a system could compensate for missing backups with excellent documentation.

Use two mechanisms:

Blocking controls#

A failed blocker prevents launch for the applicable tier.

Typical blockers include:

• No accountable owner
• No rollback or forward-recovery mechanism
• No monitoring of user-visible failures
• Untested backup restoration for durable critical data
• Known critical security vulnerability
• No incident escalation path
• Capacity below projected launch demand
• Unbounded blast radius for a high-risk release

Maturity score#

Score non-blocking capabilities on a small scale:

• 0 – absent
• 1 – documented or manually implemented
• 2 – implemented and tested
• 3 – automated and continuously verified

Use the score to prioritize improvements, not to declare a system safe by arithmetic.

4. Put the review into the delivery lifecycle#

A workable flow is:

Design checkpoint#

Triggered when the service or major change is proposed.

Outputs:

• Risk tier
• Initial SLOs
• Critical dependencies
• Data classification
• Threat model
• Availability and recovery architecture
• Named operational owner

Implementation checkpoint#

Continuously evaluated through CI/CD and the service catalog.

Examples:

• Infrastructure policies
• Dependency and vulnerability scans
• Test coverage for critical paths
• Deployment-policy validation
• Runbook and dashboard link validation
• Resource-limit checks
• Backup configuration checks

Pre-production review#

A human reviews only the items requiring judgment:

• Are the SLOs meaningful?
• Are alerts actionable?
• Are the identified failure modes credible?
• Can the on-call engineer operate the service?
• Is the launch plan appropriately staged?
• Is residual risk acceptable?

Launch authorization#

The outcome should be one of:

• Approved
• Approved with time-bound conditions
• Rejected with blocking findings
• Approved for limited exposure only

Post-launch validation#

Review actual production evidence after a defined traffic or time threshold:

• SLO behavior
• Alert quality
• Capacity assumptions
• Deployment failures
• Operational load
• Unexpected dependencies
• Cost profile

Google’s PRR process similarly moves from analysis to prioritized improvements, training, responsibility transfer, and continued learning from operation and incidents. (Google SRE)

7. Automate evidence collection#

The readiness system should pull evidence rather than asking teams to paste screenshots.

Potential integrations:

• Deployment platform: rollback and rollout configuration
• Observability platform: SLOs, alerts and dashboard ownership
• Incident system: recent incidents and outstanding actions
• Cloud/IaC platform: redundancy, backups and resource limits
• Security tooling: vulnerabilities, secrets and dependency status
• Service catalog: ownership, tier and dependencies
• Load-testing platform: latest validated capacity
• Source control: change approval and branch protection

Human review should focus on semantics and risk judgment. Machines should verify existence, freshness, configuration, and test results.

8. Define triggers for re-review#

Production readiness decays. Re-run either the full review or affected domains when:

• The service changes risk tier
• Traffic increases materially
• A critical dependency is added
• Sensitive data is introduced
• The deployment architecture changes
• Ownership or on-call responsibility changes
• Recovery objectives change
• A severe incident exposes a control gap
• A waiver expires
• The system has not been reviewed within the tier’s review period

A major change should invalidate specific controls rather than resetting the entire review.

9. Measure whether the process works#

Track process health:

• Percentage of services with current readiness status
• Percentage of controls evaluated automatically
• Median remediation time for blockers
• Number and age of waivers
• Percentage of restores, rollbacks and failovers tested recently
• Alert-actionability rate
• Readiness-review lead time

Track production outcomes:

• SLO attainment and error-budget consumption
• Incident frequency and severity
• Time to detect and mitigate
• Escaped security vulnerabilities
• Capacity-related incidents
• Deployment failures and rework
• Operational toil

For delivery outcomes, DORA’s current model uses change lead time, deployment frequency, failed-deployment recovery time, change fail rate, and deployment rework rate. These should be evaluated per application or service, since aggregating dissimilar systems obscures context. (dora.dev)

Recommended operating principle#

The central decision should be:

Does the organization have sufficient evidence that this system can be safely changed, observed, operated, degraded, and recovered within its stated business objectives?

That produces a stronger process than a static launch checklist. It connects architecture, delivery, operations, security, and organizational ownership to explicit production risk.