Release and recovery readiness: a practical deployment checklist

Assess one specific change

'We need DevOps' does not define a deliverable scope. Choose an upcoming release and record changes to code, configuration, data, scheduled jobs, and external integrations. Include the critical user journey and sensitive operating hours. In a hypothetical billing release, pages might work while an older scheduled worker can no longer read new records. The release boundary must include that consumer. Name the people responsible for each dependency and the person authorized to stop the change before deployment begins.

• Release inventory: code version, configuration, data changes, acceptance owner, and dependencies.
• Review exit criterion: every change has a verification method and a failure decision.
• For dependencies owned by another team, record coordination timing and the response owner.

Technical sources for this section: Google SRE Workbook [1]

• DevOps and deployment service scope

Demonstrate the version and destination environment

Google SRE's release-engineering principles emphasize reproducible builds, testing, and automation. For practical acceptance, someone other than the original engineer should be able to trace build inputs, the resulting artifact, and its deployment destination. This guide recommends promoting a clearly identified, approved artifact and recording configuration changes too. A test environment should have appropriate data and access of its own; naming an environment preview does not establish separation. Ask for evidence of actual project, database, and account boundaries.

Technical sources for this section: Google SRE Workbook [1]

• Evidence for a maintenance handover

Agree RTO and RPO with the business owner

In AWS guidance, RTO is the maximum acceptable delay until service restoration, while RPO concerns the acceptable time window of data loss relative to a recovery point. These are objectives; possessing a backup file does not demonstrate achievement. A hypothetical internal report and a live order ledger collecting payments may tolerate different interruptions. Instead of arbitrary targets or a zero-downtime promise, review disruption consequences, data reconstruction, and service dependencies with the operations owner, then record an achievable objective and its assumptions.

• Define the measurement boundaries: from which event until which usable journey is restored?
• The service objective must be consistent with recovery capabilities for identity, databases, and dependencies.
• If current capabilities fall short, record the gap and the decision to invest, reduce scope, or temporarily accept risk.

Technical sources for this section: AWS Well-Architected [2]

Distinguish code rollback from data recovery

For a database change, separately assess whether the previous application can use the new schema and data. In a hypothetical example, redeploying old code does not restore a deleted column that an old worker needs. A practical option is staged change: add compatible capability, migrate data with checks, move consumers, and remove the obsolete structure in a later release. Test the pattern in your actual technology. Some changes are better addressed with a forward fix, and the decision should precede the release.

• Prerequisites: review the destination, data volume, expected operation time, potential locks, and execution authority.
• Restore the backup into a separate destination and test application compatibility; a completed backup job alone is insufficient.
• Define how to reconcile data written after deployment so valid new records are not silently lost.

Technical sources for this section: AWS Well-Architected [3]

Give a gradual rollout explicit stop conditions

Google SRE describes canarying as a limited, time-bounded deployment evaluated to decide whether to proceed. A small traffic share does not automatically make a representative test: major buyers operating at particular hours must also be considered. Specify the receiving population, control version, observation period appropriate to actual usage, and stop owner before starting. A universal percentage or monitoring duration cannot replace knowledge of the service. Record the conditions under which the team will extend, pause, or reverse the rollout.

• Suggested criterion: compare errors, latency, and critical-journey failures against the baseline and agreed limits.
• If two versions write shared data incompatibly, resolve compatibility before splitting traffic.
• Record the continue-or-stop decision and its evidence; waiting a few minutes is not an evaluation.

Technical sources for this section: Google SRE Workbook [1]

Monitor the user and operational outcome

Google SRE's black-box monitoring evaluates externally visible behavior. For a billing system, a healthy home page therefore provides insufficient evidence: verify sign-in, document creation, and the resulting record. For a store, report successful payment separately from successful order creation. A practical recommendation is a focused dashboard for critical journeys, annotated with the deployed version and response instructions. Give each alert a recipient, severity, and action so the person receiving it can decide what to do rather than merely acknowledge it.

• Pair technical measures with operational signals: pending orders, failed document creation, or a processing backlog.
• Run synthetic checks with identified test accounts and data so they cannot be mistaken for actual transactions.
• Make timestamps, release versions, and tracking identifiers available to authorized responders for correlating user reports with evidence.

Technical sources for this section: Google SRE Book [4]

• Checkout and payment acceptance scenarios

Complete the work with a recovery rehearsal and ownership

AWS guidance emphasizes exercising recovery paths regularly and using runbooks during the exercise. For a planned rehearsal, specify the failure scenario, permitted boundaries, stop owner, and test data. The operator should restore a usable service using documented instructions and their own access, without relying on verbal help from the system's author. Retain measured time, data status, and unresolved gaps. That evidence applies to the tested scope and conditions; it does not guarantee the outcome of every future incident.

Technical sources for this section: AWS Well-Architected [3]