見出し画像

RTO、RPO、MTD、RLOの実務とBCP

べにや

はじめに

BCPを作る前に、指標の関係を一枚でそろえると迷いません。名前は似ていても役割は別。MTDは「事業が耐えられる停止の上限」、RTOは「再開までの目標時間」、RPOは「戻せるデータの位置」、RLOは「復旧直後の品質」。この順で並べると設計が進みます。私は現場で、まずここを可視化してから議論に乗せてきました。クラウドと外部SaaSが混在する一般的な企業システムでもそのまま使えます。

この記事で達成できること

・RTO/RPO/MTD/RLOの関係を、時間軸と品質軸で説明できる
・BIA（Business Impact Analysis／業務影響分析）を根拠に、各システムへ目標値を置ける
・段階復旧（RLO）と連絡の流れを、BCP本文に正しく結びつけられる
・演習KPIを用いて、四半期サイクルで改善できる

用語の基本

・BIA（Business Impact Analysis／業務影響分析）
　障害や災害が事業へ与える影響を、金額・法令・評判・安全の観点で評価し、復旧優先度と目標値（RTO／RPOなど）の根拠にする手順です。結果はBCPの前提になります。

・RTO（Recovery Time Objective）
　停止から業務再開までに許容する時間の目標。手順、体制、権限の設計で上下します。

・RPO（Recovery Point Objective）
　復旧時点からどこまでデータを戻すかの目安。取得方式と検証品質に依存します。バックアップ間隔と同一視しません。

・MTD（Maximum Tolerable Downtime／MTPD）
　事業として耐えられる停止の上限。経営の合意が要ります。

・RLO（Recovery／Required Level Objective）
　復旧直後に提供する最低サービス水準。段階復旧の基準として扱います。本稿ではISO 22301のMBCO（Minimum Business Continuity Objective）に近い概念として用います。

・BCP／DRP
　BCPは事業継続の枠組み全体、DRPはITの復旧計画。指標はBCPで宣言し、達成手段はDRPへ分解します。

関係の図解

時間と品質を並べて関係を固定します。MTDが上限、RTOはその内側、RPOは巻き戻せる位置、RLOは復旧直後の品質です。

```mermaid
graph LR
  MTD[MTD: 事業が耐えられる停止の上限] --> RTO[RTO: 再開までの目標]
  RTO --> RLO[RLO: 復旧直後の最低水準]
  RPO[(RPO: 巻き戻し位置)] -. 時間軸の参照点 .-> RTO
```

要点は三つだけです。
・MTD ＞ RTO
・復旧時刻 − RPO ＝ 復元データの最新時刻
・復旧後のサービス水準 ≥ RLO

指標の決め方：BIAから逆算

  1. 影響の見積もり
    　売上欠損（円／時間）、契約上の違約金、規制報告の要否と期限、問い合わせ件数の見込み、安全への影響。測定単位と閾値を先にそろえ、優先度へ変換します。

  2. 依存関係の棚卸し
    　DB、ID基盤、決済、外部SaaS、ネットワーク、監査ログ。復旧の先後関係を付記します。

  3. 現行能力の実測
    　復元検証の成功率、復元に要する時間、フェイルオーバー所要、ランブックの粒度、オンコール集合時間。体感ではなく測ります。

  4. RPOの初期案
    　トランザクション、カート、メディア、監査ログを分けます。同期／非同期、ジャーナルの有無を併記します。

  5. RTOの初期案
    　手順の段数、事前委任、スクリプト化、人的ボトルネックで決まります。承認待ちが長いほど延びます。

  6. RLOの段階設計
    　L1（読取専用）→L2（コアAPI）→L3（通常）。各段階の到達時間と制約を並べます。

  7. MTDの合意
    　BIAの結果を根拠に、経営会議で決めます。現場裁量にしません。

  8. コスト曲線の提示
    　RTO／RPOを縮めるほど費用は逓増します。多AZ、多リージョン、同期複製、整合要件を並べ、着地点を作ります。

私の経験では、RTO短縮はツール投入よりも、権限と手順の粒度で効く場面が多いです。1操作1段のランブックと事前委任。ここを先に整えると数字が動きます。

実務への当てはめ

・取引系
　RPOは短め。RTOは自動化前提。まず閲覧再開、続けて決済再開。

・分析系
　RPOは緩めに置けます。欠損の扱い（補完／再計算）を先に決めます。

・社内基盤
　ID、メール、チャットはBCP側で代替手段を確保します。

・データ面の分離
　- txn：秒〜分。同期＋ジャーナル
　- cart：再送前提で分離
　- media：遅延許容
　- audit：完全性優先で独立保存

・RLOの段階例
　- L1：5分以内に読取専用、バッチ停止
- L2：15分以内にコアAPI開放
- L3：通常運転

BCPの中での置き場所

BCPには、方針、発動／終了基準、指揮系統、連絡、代替拠点、勤務形態、演習までを含めます。指標はBCP本文の「基準値」として宣言し、DRPへ達成手段を分解します。外部SaaSのRTO／RPO、通知義務、補償上限は契約条項から抜粋し、責任境界を文章と図で固定します。

図解：フェイルオーバーの流れ

```mermaid
sequenceDiagram
    participant Mon as 監視
    participant LB as ロードバランサ
    participant Pri as プライマリ
    participant DR as 代替サイト
    participant Ops as 運用

    Mon->>LB: 異常検知
    activate Mon
    LB-->>Pri: ヘルスチェック失敗
    deactivate Mon
    LB->>Ops: アラート送信
    activate Ops
    Ops->>LB: トラフィック遮断
    LB->>DR: フェイルオーバー指示
    activate DR
    DR-->>LB: L1到達（読取専用）
    Ops->>DR: ランブック実施
    DR-->>LB: L2到達（コアAPI）
    DR-->>LB: 通常運転へ切替（RTO到達）
    deactivate DR
    deactivate Ops
```

実例：ECサイト

条件：日商1200万円、ピークQPSが高い、決済は外部依存。整合の線引きを先にやります。

ec_workload:
  traffic:
    peak_qps: 850
    p95_latency_ms: 300
  data_planes:
    txn: sync_replication+journal
    cart: async+journal        # 再送で整合回復
    media: eventual
    audit: append_only+独立保存
  targets:
    RPO:
      txn: "PT1M"
      cart: "PT2M"
      media: "PT10M"
      audit: "PT5M"
    RTO: "PT15M"
    MTD: "PT60M"               # 役員合意
    RLO:
      - level: L1
        window: "PT5M"
        scope: ["catalog", "order-read"]
      - level: L2
        window: "PT15M"
        scope: ["order-core", "payment"]

多AZは前提に置きます。多リージョンは決済の整合、顧客通知、コストの兼ね合いで判断します。カートの再送と払い戻し条件は、顧客向け告知テンプレと連動させます。

実例：社内ID基盤

・RPO：0〜5分（認証情報は同期、監査ログは独立保存）
・RTO：30分（冗長コントローラとキャッシュを併用）
・MTD：120分（暫定手段をBCPに記載）
・RLO：認証のみ→簡易認可→通常。管理系APIは最後に開放します。

検証と運用：測る・試す・直す

・観測KPI
　- 復元検証の成功率
　- 復旧ドリルの所要時間（中央値・最大）
　- 連絡テンプレ配布から初回対外通知までのリードタイム
　- 権限エスカレーション待ち時間の中央値
　- 手動介入回数／フェイルオーバー実行回数

・演習
　最短経路で回し、段差、承認待ち、合流点の詰まりを記録します。

・是正
　手順は1操作1段へ分解。委任は事前設定。繰り返しはスクリプト化。

・見直し
　四半期ごとにKPIと指標を更新し、変更管理とセットで配布します。

アンチパターン

・取得だけで満足し、復元検証をしない
・横串の合成でRTO／RPOが破綻
・現場判断でMTDを設定し、経営合意がない
・RLO未定義で「全部戻るまで公開停止」
・DRPだけで完結させ、体制・連絡・代替手段が空欄
・外部SaaSの条項を読まず、責任境界が曖昧

まとめ

三つのシステムを選び、RTO・RPO・MTD・RLOを置いてください。30分の机上演習を一度回し、詰まりとリードタイムを記録します。ログから、手順の粒度、権限の委任、自動化の三点を一つずつ直し、四半期で再検証します。地道ですが、再現性があります。

チートシート／テンプレート／チェックリスト

ここから先は

1,687字

¥ 100

ログイン

この記事が気に入ったらチップで応援してみませんか？