← Application Production Support
09 / 10 · 60 MIN

Operational acceptance and recovery

Validate data, compatibility, and execution context before accepting recovery or RUN handover.

Define the milestone being accepted

Completion of a restore command is a technical milestone. The service requirement may demand complete, correct, usable cycle results within twenty minutes. Write that milestone before rehearsal to avoid changing the criterion to match observation. Distinguish file receipt, consumer reconciliation, and business availability. A receipt acknowledgement does not automatically cover later stages. Also include service scope and dependencies supporting the deadline. If a team only acknowledges requests within thirty minutes, that commitment does not establish capability to recover service within fifteen. The mismatch needs an explicit decision.

Reconcile snapshot content

The laboratory creates eight local results, takes a snapshot using the backup API, and only then adds results 9 and 10 to the source. It restores the snapshot into another temporary database. integrity_check returns ok, but comparison against the expected set finds only eight results. A retained fictional journal contains 9:90 and 10:100. Local recovery checks identities and values before inserting; two applications of that journal leave ten results and 550 units. The experiment demonstrates the effect on this local set. It executes no external replay, validates no actual journal provenance, and does not prove this strategy suitable for every processing contract.

Separate structure, relationships, and application

In the compatibility fixture, the snapshot predates column status. The new application tries to query it and receives no such column: status despite integrity_check returning ok. In a separate independent fixture, foreign_keys was deliberately disabled before inserting a row linked to nonexistent batch 99. Structural checking still returns ok while foreign_key_check identifies the invalid relationship. These illustrate different validation scopes. Do not conclude that enabling enforcement automatically repairs old data. Reconcile relationship meaning and confirm the application, schema, and data combination. Indiscriminately deleting rows can produce an apparently clean database and incomplete business output.

Bind evidence to actual context

The readiness model compares artifact, configuration, runbook, and operating role. Evidence refers to build-a, cfg-3, revision 4, and aps-run. The candidate retains the binary but changes configuration and runbook; the model identifies both differences. A case with every field matching passes comparison. This synthetic control neither authenticates approvers nor replaces technical review. It prompts asking whether evidence applies to what will execute. Configuration changes can alter connections or limits without changing the binary. A role change can alter permissions. Assess impact and define required rehearsals for the actual candidate before the acceptance decision.

Manage exceptions and coordination during recovery

The exercise’s fictional policy defines an exception as valid only while current time is before 12:00 UTC. The model accepts 11:59 and rejects 12:00. The boundary is explicit and represents no universal policy. If the gap remains open, obtaining a new decision differs from editing the date to extend an old one. During an incident, also coordinate proposed changes with those managing recovery. A project changing configuration while another team tests hypotheses can invalidate evidence or create incompatible effects. Retain chronology, owners, and authorized scope. Urgency calls for decision clarity, not an assumption that every action is approved.

Prepare a usable acceptance package

Deliver a summary containing requirements, tested combination, outcome, gaps, owners, and review conditions. For a supplier, include version, reproducible steps, and minimally relevant evidence through an authorized channel. Protect data unnecessary for diagnosis; removing sensitive information does not mean removing timestamps or useful technical context. Identify what actually executed and what remains a model or proposal. In this laboratory, four groups use actual SQLite in disposable files; readiness controls are fictional comparisons. There was no production restore, real permission test, or human decision. The workshop ends with a reasoned package for review, not official certification or operating authorization.

python3 content/labs/aps-readiness/run.py
# Disposable SQLite fixtures; no application database or network
# Recorded: CPython 3.13.1 / SQLite 3.53.4
# integrity_check = ok; restored rows = 8; expected rows = 10
# Old snapshot + new reader: no such column: status
# Separate fixture: integrity_check = ok; foreign_key_check reports a violation
# Eleven groups distinguish actual SQL from synthetic decision models.
IN PRACTICE

A snapshot is structurally valid but lacks current-cycle results. The team must reconcile the set and confirm compatibility with the application that will operate.

Common pitfalls

Accepting on one green command, reusing evidence after material changes, or treating an automated model as an authorized human decision.

Related topics: Disaster Recovery · Change Management · SQL

Take this idea with you

Acceptance connects requirements to observations in the context that will be operated. Record gaps, decision validity, and ownership of remaining work.

Create account

Reference: Consistent review of operational readiness · BigSavant APS professional curriculum 2026-09; vendor-neutral operational guidance reviewed 2026-09-30