BRIEF / 02.A.01
The problem
A platform can run on several servers and still have a single point of interruption: a database, administrative identity, storage, network or provider. Design starts with the value of the service and the consequences of losing it.
BRIEF / 02.A.02
Continuity objectives
RTO — Recovery Time Objective — expresses the required recovery time. RPO — Recovery Point Objective — defines the tolerable loss of recent data. Objectives concern the application functions that must return, rather than server startup alone.
BRIEF / 02.A.03
Architecture and failure domains
HA — High Availability —, load balancing and replication are assessed against actual failure domains. The design addresses database consistency, shared dependencies and network partitions. Replication does not replace recovery from a propagated logical error.
BRIEF / 02.A.04
From design to service
Implementation can include load balancing, database HA, segregated copies and promotion and recovery procedures. Compute, storage and networking can come from third-party providers; responsibilities and dependencies remain explicit.
BRIEF / 02.A.05
How verification works
Agreed tests observe failure behaviour and the return of application functions. Measured timings and the recovered data point are compared with RTO and RPO. Restore is checked through the usability of the service.
BRIEF / 02.A.06
Management and operating commitments
SLA — Service Level Agreement —, response times, monitoring and escalation are defined where included in the engagement. A test result describes the conditions observed; it does not by itself guarantee behaviour under every possible failure.