In this chapter
11.1 Define the operating envelope
Infrastructure selection begins with approved data placement, workload, availability, recovery and support constraints. For the fictional institution, local control is a candidate requirement to validate, not a claim about an existing installation. A deployment diagram must distinguish logical roles from independent physical failure domains. Two containers on one host do not provide host resilience. Replication is not a backup. An untested disaster-recovery diagram is an intention, not a demonstrated capability. Each claim requires a failure model and an exercise.
11.2 Candidate deployment view
This conceptual view separates access, application processing, authoritative storage and protected recovery copies. It deliberately does not prescribe a highly available cluster for a team that has not established its operating capacity. The final design must choose host count, power, network, storage and recovery locations against approved objectives.
11.3 Recovery objectives and cost
| Item | Scenario candidate | Decision or evidence needed |
|---|---|---|
| Recovery point | At most 24 hours of data loss | Business impact and permitted loss window |
| Recovery time | Restore essential journey within 4 hours | Timed exercise including application and data checks |
| Backup protection | Separate access from routine application operation | Credential and deletion-control review |
| Restore scope | Data, attachments, configuration and keys | Complete dependency inventory |
| Degraded operation | Draft work preserved; final approval waits | Branch continuity and communication policy |
A candidate objective becomes a commitment only when scope, exclusions, dependencies, staffing and cost are approved. Record which functions return first and which manual reconciliation is required after restoration.
11.4 Release engineering
Every release identifies source revision, artifact, configuration, schema change and verification result. Required checks follow the risk. A schema change may require compatibility tests and a staged migration; an access change needs negative authorization tests. The recovery plan distinguishes application rollback, forward repair and data restoration. Reusing a previous container image does not undo a destructive data change. The release owner must know which strategy is permitted before deployment.
11.5 Continuity exercise
Simulate a defined failure in an authorized isolated environment. Record detection, decision, restoration, reconciliation and return to service. Compare actual results with the approved objectives and record corrective work. An exercise that omits attachments or required keys cannot establish complete recovery.
11.6 Acceptance package
Deliver the deployment view, failure-domain inventory, release procedure, protected backup policy and restore runbook. The system owner accepts operating responsibility; the sponsor accepts the residual continuity cost and risk. Infrastructure complexity expands only when its benefit and ownership are explicit.