Business Continuity Requirementの設計

1. ビジネス継続性はビジネス関数から考える

ビジネス継続性は、障害や災害が起きても重要なビジネス関数を継続する、または許容時間内に再開するための考え方です。災害復旧計画はIT ワークロードの復旧を扱い、ビジネス継続性計画の一部としてビジネス要件に整合させます。

ビジネス継続性計画
├─ ビジネス 処理
├─ 人 / 組織
├─ 外部依存関係
└─ 災害復旧計画
    └─ IT ワークロード復旧

IT システムだけが復旧しても、ビジネスプロセス全体が機能しなければビジネス継続性要件を満たしたとはいえません。

2. ビジネス影響から重要度を決める

すべてのワークロードへ同じ復旧要件を設定するのではなく、停止やデータ損失がビジネスへ与える影響から重要度を決めます。

サーバー台数やクラウドコストではなく、ビジネス影響が重要ワークロードを識別する基準です。

3. RTO / RPOをビジネス要件として固定する

復旧時間目標（RTO）と復旧ポイント目標（RPO）は、アーキテクチャを選んだ後に決める値ではありません。ビジネス影響から許容できるサービス復旧時間とデータ損失を要件として先に固定します。

ビジネスへの影響
      ↓
RTO / RPO
      ↓
障害範囲 / 依存関係と組み合わせる
      ↓
アーキテクチャ候補を比較

ここで重要なのは定義の暗記ではなく、現在バックアップ間隔や現在復旧時間をそのまま目標へ置き換えず、ビジネス側の許容値として扱うことです。

4. 目標と実装を混同しない

RPO = 15 分は「バックアップを必ず15分間隔で取得する」という実装ではありません。ビジネスが許容するデータ損失を定義し、その目標を満たすレプリケーションやバックアップを後から選択します。

ビジネスへの影響
↓
RTO / RPO
↓
復旧要件
↓
技術アーキテクチャ

既存アーキテクチャが実現できる数値を、そのままビジネス要件として逆算しません。

5. ビジネス目標と実現可能性をすり合わせる

復旧目標はビジネス影響を出発点にしますが、必要以上に厳しいRTO / RPOは復旧コストや複雑さを増やします。また現在の技術や依存関係では目標を達成できない場合もあります。

ビジネスへの影響
↓
初期 RTO / RPO
↓
障害リスク / 発生確率
復旧コスト
技術的実現性
依存関係
↓
妥当かつ達成可能？
├─ はい → 復旧要件を確定
└─ いいえ → ビジネス / 技術チームで再評価 ↺

技術チームだけで目標を緩和するのでも、ビジネス側が技術的実現性を無視するのでもなく、必要なビジネス値と実現可能性を合意します。

6. 障害範囲を明示する

「障害に強くする」では、どこまで保護するか判断できません。復旧要件には対象障害範囲を明示します。

リージョン規模の障害をビジネス継続性の対象にするなら、まずそれを要件として明示し、マルチリージョン等の具体的解決策はその後に比較します。

7. 障害範囲やビジネスコンテキストで目標は変わり得る

同じワークロードでも、障害シナリオによって許容できる復旧目標が異なる場合があります。

AZ 障害
RTO = 5 分

リージョン規模の災害
RTO = 2時間

また季節的イベント、製品開始、決算処理、契約 / 規制変更などでビジネス影響が変われば、必要な復旧目標も再確認します。

8. 上流 / 下流依存関係を含める

ワークロード単体のRTO / RPOだけでは、エンドツーエンドのビジネスサービスを復旧できません。

上流
→ このワークロードに依存する側
→ より厳しい復旧要件を要求し得る

下流
→ このワークロードが依存する側
→ 復旧機能がボトルネックになり得る

例えばアプリケーションのRTOが15分でも、必須データベースが2時間でしか復旧できないなら、依存関係の機能改善、回避策、またはビジネス要件の再評価が必要です。

9. 復旧要件を測定可能にする

「できるだけ早く復旧」「データ損失をなるべく減らす」ではアーキテクチャ候補を比較できません。

ビジネス関数 / ワークロード:
注文処理

障害範囲:
リージョン規模の障害

RTO:
30 分

RPO:
5 分

ワークロード、障害範囲、RTO、RPOを明示することで、候補アーキテクチャが要件を満たすか評価できます。

10. 要件と解決策を分離する

「マルチリージョンアクティブ-アクティブを使用する」は解決策です。ビジネス要件が「リージョン規模の障害でもRTO 5 分、RPO 1分」なら、その要件を満たす複数候補を比較できます。

復旧要件
→ 何を達成する必要があるか

アーキテクチャ
→ どう実現するか

特定サービスやパターンを要件へ埋め込まず、まず達成すべき復旧目標を固定します。

11. 障害モード

12. SAP-C02判断フロー

ビジネス関数
↓
ビジネスへの影響を評価
↓
重要度を決定
↓
障害範囲を決定
↓
RTO / RPOを定義
↓
上流 / 下流依存関係を確認
↓
リスク / コスト / 技術的実現性を確認
↓
復旧目標は妥当・達成可能？
├─ いいえ → ビジネス / 技術チームで再評価 ↺
└─ はい
    ↓
復旧要件を文書化
    ↓
アーキテクチャ候補を比較