4.1IT service continuity management (ITSCM), BCP, and disaster recovery

For a service manager, service continuity is not about aiming to "never let anything go down." Preventing every possible failure is not cost-effective, so the essence is to work backward from business impact to decide "how much downtime and data loss to tolerate, and how much to spend on measures to achieve it." Grounded in the position of ITSCM—which handles IT recovery within the business-wide BCP—this section builds the judgment to choose recovery objectives (RTO/RPO/MTPD) and a recovery-site approach within the tradeoff between business impact and cost.

4.1.1The relationship between ITSCM and the BCP

• A BCP (business continuity plan) is the business-wide plan for restoring and continuing core business within a tolerable time when operations are interrupted by a disaster, system failure, pandemic, or the like. Its scope is not limited to IT; it includes staff, sites, the supply chain, and alternative means. ITSCM (IT service continuity management) is the service-management process that plans, prepares, and rehearses the recovery of IT services so as to meet the business recovery objectives set by that BCP. In other words, ITSCM is a part of the BCP: the BCP is the higher-level plan and ITSCM is subordinate to it.
• ITSCM is not a matter of "write a recovery plan and be done"; it is a continuous activity that includes periodic rehearsals and tests (actually switching over) and revising the plan to match business and system changes. If the plan does not reflect the latest system configuration, the recovery procedure will not work when it matters—eliminating the procedure obsolescence and overlooked dependencies that only surface in a rehearsal is what determines ITSCM's effectiveness.

4.1.2RTO, RPO, and MTPD

• The RTO (recovery time objective) is the target time from the failure until the service is restored ("within how many hours to restore"—the downstream direction on the time axis). The RPO (recovery point objective) is the target point in time to which data can be rolled back on recovery ("how far back in time of data loss is tolerable"—data upstream of the failure moment). RTO defines the speed of recovery and RPO defines the tolerable amount of data loss; they are separate axes.
• The MTPD (maximum tolerable period of disruption; also MAO) is the absolute upper limit of downtime the business can withstand, beyond which its survival is jeopardized. The RTO must always be set shorter than the MTPD (recovery must complete before the MTPD is reached). The shorter the RPO (the smaller the data loss), the higher the frequency of backup/replication and the equipment cost; the shorter the RTO (the faster the recovery), the higher the cost of standby facilities—the tradeoff that tighter recovery objectives cost more is decided through a business impact analysis (BIA).

4.1.3Recovery sites (hot/warm/cold) and remote location

• A hot site keeps a standby system with equipment and data synchronized to production in near real time, always running, allowing switchover with very short RTO/RPO, but because it maintains duplicate facilities it is the costliest. A warm site is an intermediate form that provides hardware and software while transferring data periodically, giving moderate RTO/RPO and moderate cost. A cold site secures only power, air conditioning, and floor space, bringing in and setting up equipment after a disaster, so its RTO/RPO is long (recovery takes days) but it is the cheapest.
• A recovery site should in principle be placed at a remote location far enough not to be struck by the same disaster as the production site. Placing the standby within the same data center or nearby means a large earthquake, wide-area power outage, or flood can wipe out production and standby together, rendering the continuity measure meaningless. However, the more remote the site, the greater the line latency, operator travel, and cost, so the location is decided by balancing "a distance that avoids simultaneous impact" against "synchronization performance, operability, and cost."

Suppose the service manager of an online payment service is re-examining the approach for its disaster-recovery site. A business impact analysis (BIA) has found that payment processing, if down for more than 4 hours, threatens business survival through merchant attrition (MTPD = 4 hours), and that not a single payment record may be lost (RPO ~ 0). The first thing to decide is to set the RTO reliably shorter than the MTPD (4 hours)—say, within 1 hour. When choosing a recovery site, a cold site is rejected because bringing in equipment takes days and cannot possibly meet a 1-hour RTO, and a warm site is rejected because its periodic data-transfer method cannot meet a near-zero RPO. Therefore a configuration that stands up a hot site at a remote location and replicates payment data to the standby in real time (synchronous replication) meets the requirements. It would be a serious error to reason, for the sake of cost reduction, that "putting the standby in the same data center as production would cut line latency and cost too"—at a single site, a large-scale disaster wipes out production and standby together, so the continuity measure itself does not hold. Because synchronous replication to a remote site can degrade payment response through line latency, the synchronization method, line bandwidth, and consistency guarantees must be designed together. A service manager judges in this order: first fix the business requirements RPO and RTO as numbers, eliminate the approaches that cannot meet those numbers, and only then compare the remaining options on cost and operability. Starting from cost before fixing the requirements leads to picking a cheap approach that fails to meet them.

4.1.4Section summary

• ITSCM is a continuous activity that plans, rehearses, and revises IT-service recovery as part of the business-wide BCP
• RTO is the target time to recover, RPO is the point in the data timeline to restore to (tolerable data loss)—separate axes—and the MTPD is the absolute downtime limit, with RTO < MTPD
• Recovery sites (hot/warm/cold) trade RTO/RPO against cost, and are placed in principle at a remote location that avoids simultaneous impact