SERVICE CONTINUITY · RECOVERY OBJECTIVES
障害復旧の目標を図解する
RTO・RPO・RLO
システムが止まったとき、どの時刻までに、どこまでデータを戻し、どのサービスを利用可能にすればよいのか。復旧を「時間・データ・機能」の3軸で設計する。
1. 災害時に「復旧した」の意味は一つではない
病院の予約サービスが停止した場面を考えます。サーバを再起動できても、今日の予約情報が消えていたら業務は続けられません。反対に予約情報をすべて復元できても、予約画面が明日まで利用できなければ現場は困ります。さらに、緊急患者の照会が動けば当面よいのか、すべての機能を同時に復旧させる必要があるのかでも対応は変わります。
そこで、復旧計画では「時間（RTO）」「データ時点（RPO）」「サービス範囲（RLO）」を別々に合意します。
2. 一本の時間軸でRTO・RPO・RLOを理解する
図では00:00が最新の復元可能な時点、04:00に障害、06:00に重要機能が再開。RPOは4時間、RTOは2時間、RLOは「重要機能のみ」です。06:00にすべての機能と最新データが戻る、という意味ではありません。
3. RTO：いつまでに業務を再開するか
Recovery Time Objective — 目標復旧時間
「障害発生から2時間以内に予約の受付を再開する」という目標です。停止の検知、対応判断、切替、データの検証、利用者が使えることの確認までの段取りを考える必要があります。
RTOが2時間なら、実際に2時間経過してもよいという意味ではありません。早く復旧できるほど望ましく、達成状況は障害対応訓練・記録で確認します。
4. RPO：どの時点のデータに戻せるか
Recovery Point Objective — 目標復旧時点
「障害発生の最大15分前の状態まで復元できる」という目標です。例として10:00に障害が起きた場合、09:45のデータまで復元できればRPO15分を満たします。
15分間の注文や予約の更新は失われる可能性があり、復旧後に再入力・照合が必要な場合があります。バックアップ周期だけでなく、バックアップの成功確認やレプリケーション遅延も関わります。
5. RLO：何をどこまで使えるようにするか
Recovery Level Objective — 目標復旧レベル
「24時間以内に重要な受付機能と照会機能を復旧し、通常処理能力の50%以上を確保する」のように、復旧時のサービス内容と規模を示します。
RTOを短くするため、まず重要機能だけを再開して、後から帳票・分析などを復旧する段階的な計画が考えられます。段階ごとにRTOとRLOを対で決めることも有効です。
6. 4つの事例を3軸で分類する
| 復旧方針の例 | RTO | RPO | RLO |
|---|---|---|---|
| 中断前3時間のデータに戻し、利用者50%以上に提供 | — | 3時間前 | 50%以上 |
| 中断直前のデータに戻し、終了時間を延長 | — | 直前 | — |
| 中断から1時間以内に、1時間前のデータに戻す | 1時間以内 | 1時間前 | — |
| 中断から1日以内に重要サービスだけ再開 | 1日以内 | — | 重要機能のみ |
問55に相当する組み合わせは最後の行で、「1日以内」＝RTO、「重要サービスだけ」＝RLOです。データの復元時点については記述していないため、RPOは特定されません。
7. 復旧は複数の段階を踏む
機械が起動したことと、利用者が業務を再開できることは異なります。復旧手順書には、依存先、必要なデータ、認証、ネットワーク、試験、連絡、代替手段を整理します。
8. バックアップ・レプリケーション・冗長化
バックアップ
過去のデータを保存し、誤削除や破損から復元。取得間隔はRPOに、復元所要時間はRTOに関係します。
レプリケーション
データを別の装置・拠点へ複製。同期方式・遅延・論理的な誤操作の伝播に注意します。
冗長化／切替
予備機や複数拠点を準備し、障害時に切替。短いRTOを狙えますが、データ整合性も別途必要です。
9. 復旧方式の選択とトレードオフ
| 構成例 | 復旧の特徴 | 考えるべき点 |
|---|---|---|
| バックアップから再構築 | 基盤・データを一から戻す | 復元に必要な容量・手順・時間 |
| コールドスタンバイ | 予備の環境を事前用意せず、または停止状態から起動 | 起動・設定・データ投入の時間 |
| ウォームスタンバイ | 一部を起動・同期した待機環境 | 同期遅延、切替手順、費用 |
| ホットスタンバイ／高可用性構成 | 稼働中の予備系へ迅速に切替 | 障害の共通原因、整合性、運用費 |
一般に短いRTOや小さいRPOを求めるほど設備費・運用費・設計の複雑さは増えます。実際の所要時間は製品や環境に依存するため、方式だけで保証できるわけではありません。
10. BIAで重要業務から優先順位を決める
BIA（Business Impact Analysis：事業影響度分析）では、業務が1時間・1日・3日止まった場合の損害、法的な影響、取引先・利用者への影響を評価します。「全部を30分以内に戻す」と決めるのではなく、影響が大きい業務を先に復旧する根拠をつくります。
MTPD（最大許容停止時間）は事業が中断に耐えられる限界。RTOは、その上限を超えないよう、作業上の余裕も考慮して設定します。
11. BCP・BCM・DRPの役割分担
BCPは人員・施設・手順・代替業務を含む事業継続計画、BCMは事業継続を維持改善する管理活動、DRPはITなどの災害復旧の具体的な計画を指します。ITだけ復旧しても業務担当者が不在なら事業は再開できません。
12. RTOとMTTRは違う
RTOは事前に決める復旧目標、MTTRは障害対応の実績を集めた平均復旧時間です。平均がRTO以内でも長時間の障害が時々発生する可能性があるため、平均値に加えて最大値・分布・達成率も確認します。
13. 可用性・SLAとの関係
可用性99.9%という数値は、集計期間内にどれだけ稼働していたかの割合です。RTOの「個別の障害から何時間で復旧するか」とは異なります。SLA（サービスレベル合意）は期待する水準を関係者間で定める文書や合意で、復旧条件を含む場合もあります。
14. 操作して復旧目標の意味をつかむ
次のラボでは、障害発生時刻、RTO、RPO、重要機能の復旧率、バックアップ間隔と復旧作業時間を変更して、実際の設計案が目標を満たすか試せます。
ラボ① RTO・RPO・RLOを設定する
架空のサービスで復旧目標を設定し、同じ障害に対する復旧案が目標を満たすか確認します。
RTO の目標
2時間
12時までに目標サービスを再開
RPO の目標
1時間
障害前どの時点まで復元するか
RLO の目標
60%
復旧時に提供するサービスの規模
ラボ② バックアップと復旧案の達成判定
バックアップは0時を起点に等間隔で取得するモデルです。「複製を利用する」を選ぶと、データの復元点が障害15分前になると仮定します。
結果：少なくとも1つの目標が未達
RTO・RPO・RLOは別々の評価軸です。復旧時間が十分でも、データや機能の目標が不足することがあります。
ラボ③ どの復旧指標の組み合わせ？
「24時間以内に、決済と注文確認だけを復旧する」という方針が示す2つの指標を選びましょう。
15. 混同しやすい用語まとめ
RTO — Recovery Time Objective
サービス中断後、目標とする水準のサービスを再開するまでの最大許容時間を定める。
RPO — Recovery Point Objective
データをどの過去時点まで復元するかの目標。時点から障害までの更新データは失われ得る。
RLO — Recovery Level Objective
復旧時に提供できるサービス範囲・機能・処理能力などの目標水準。
MTTR — Mean Time To Repair/Restore
平均修復・復旧時間の実績指標。目標であるRTOとは区別する。
MTPD — Maximum Tolerable Period of Disruption
事業が耐えられる中断の上限。RTOの決定根拠となる。
BIA — Business Impact Analysis
業務停止による損害と時間経過の影響を調べ、優先順位や目標を決める。
BCP — Business Continuity Plan
災害時に重要業務を続け、復旧するための計画。
DR — Disaster Recovery
災害・重大障害で停止したITの復旧策。BCPのうちIT復旧を支える領域。
16. まとめ：3つの質問で復旧目標を設計する
決める順番
- いつまで？（RTO） — 障害から何時間以内か。
- どこまで過去に戻ってよい？（RPO） — 許容できるデータ更新の損失範囲はどれくらいか。
- どの程度のサービスを？（RLO） — 優先する機能・ユーザー数・処理能力は何か。
復旧の設計で大切なのは、システムの再起動を目的にしないことです。事業に必要な機能が、許容される時間とデータの範囲で、本当に利用可能になるかを確認します。