ある組織では、オンライン受注システムを、業務上もっとも重要なサービスの一つと位置づけていました。
障害が発生し、復旧作業が始まりました。担当者は当然、この最重要システムから復旧させようとしました。
しかし、実際には、オンライン受注システムをそのまま単独で復旧させることはできませんでした。
このシステムは、次のような基盤的な仕組みに依存していたのです。
ネットワーク
↓
DNS
↓
Identity（認証・認可）
↓
ストレージ
↓
データベース
↓
アプリケーション実行基盤これらの依存先が利用できる状態になって初めて、オンライン受注システムは実際に使える状態になります。
担当者は、ここで一つのことに気づきました。
「業務上もっとも重要だと考えていたもの」と、「実際に技術的に最初に復旧できるもの」は、必ずしも同じではありません。
この章では、この違いについて整理していきます。
6.1 「重要」「優先」「順序」は同じではない
Chapter 4では、業務機能ごとに、中断したときの影響が異なることを見ました。
ここから、「業務上どれだけ重要か」という考え方が生まれます。しかし、それがそのまま「実際にどの順番で復旧できるか」を意味するわけではありません。
この章では、次の3つの考え方を分けて整理します。
- Business Criticality（業務上の重要度）
- Recovery Priority（復旧の優先度）
- Technical Recovery Order（技術的な復旧順序）
これらは互いに関連していますが、同じものではありません。ある業務が「重要」であることと、それを「優先して戻したい」と考えることと、実際に「その順番で戻せる」ことは、それぞれ別の問題です。
なお、この3つの用語は、この章での考え方を整理するための呼び方であり、特定の業界標準や規格が定めた分類ではありません。
6.2 Business Criticality — 業務上の重要度
Business Criticality（業務上の重要度）とは、ある業務機能やシステムが、組織にとってどれだけ重要かという観点です。
Chapter 4で見たように、業務機能によって、中断したときの影響は異なります。外部の顧客に直接影響する業務、他の業務の前提になっている業務、法令や契約に関係する業務など、影響の大きさや性質はさまざまです。
Business Criticalityは、こうした業務影響の分析から見えてくる、業務上の重要さの評価です。
ここで注意したいのは、Business Criticalityは、技術的な復旧順序そのものを表すものではないという点です。ある業務が重要であるということと、それを最初に技術的に復旧できるということは、別の話です。この点については、6.4で改めて整理します。
6.3 Recovery Priority — 復旧の優先度
Recovery Priority（復旧の優先度）とは、組織として、どの業務やシステムを優先して復旧させたいかという考え方です。
Recovery Priorityは、Business Criticalityの影響を受けます。業務上重要だと考えられているものほど、優先して復旧したいと考えるのは自然なことです。
ただし、Business CriticalityがそのままRecovery Priorityを自動的に決めるわけではありません。組織の状況や制約によって、実際に「何を優先するか」という判断には、業務上の重要度以外の要素も関わってきます。
そして、ここがこの章の中心的な論点なのですが、Recovery Priorityが決まったとしても、それがそのままTechnical Recovery Order（技術的な復旧順序）になるとは限りません。
すべてのシステムに同じ水準の保護や復旧要件を適用することは、コスト、人員、運用負荷の面で現実的でないことがあります。重要なのは、必要な対策を単に「高コストだから実施しない」とするのではなく、業務への影響や利用できるリソースを踏まえて、どのリスクを低減し、どのリスクを残すのかを明示的に判断することです。すべてのリスクをなくすことはできません。だからこそ、残るリスクを把握したうえで受容することと、十分に検討しないまま放置することは分けて考える必要があります。
6.4 Technical Recovery Order — 技術的な復旧順序
Technical Recovery Order（技術的な復旧順序）とは、実際に技術的な観点から見て、どの順番で復旧作業を進める必要があるかということです。
ここで重要になるのが、依存関係（dependency）です。
あるシステムが正常に動作するためには、多くの場合、その前提となる別の仕組みが先に復旧している必要があります。冒頭のシナリオで見たように、ネットワーク、DNS、Identity、ストレージ、データベースといった基盤的な仕組みが利用できなければ、その上で動くアプリケーションは、たとえ復旧作業を試みても実際には機能しません。
このため、業務上もっとも重要で、もっとも優先して復旧したいと考えているシステムであっても、技術的には、それを支える基盤的なサービスの復旧が先になる場合があります。
これは、優先順位の判断が間違っているという意味ではありません。Recovery Priority（何を優先したいか）と、Technical Recovery Order（技術的に何が先に必要か）は、そもそも別の観点から生じるものだということです。
6.5 業務優先度と技術的順序が食い違う例
冒頭のシナリオに戻ります。
組織は、オンライン受注システムをRecovery Priorityの観点でもっとも優先していました。しかし、Technical Recovery Orderの観点では、次のような依存関係が存在していました。
Example dependency-driven recovery sequence
（あくまで一例であり、すべてのシステムに共通する固定的な順序ではありません）
ネットワーク
↓
DNS
↓
Identity
↓
ストレージ
↓
データベース
↓
アプリケーション実行基盤
↓
オンライン受注システムこの例では、オンライン受注システムというRecovery Priority上もっとも重要視されていたサービスが、Technical Recovery Orderの上では、実は最後に位置しています。ネットワークやDNS、Identityといった、普段は意識されにくい基盤的な仕組みが、技術的には先に復旧している必要があるのです。
この依存関係の具体的な形は、システムの構成によって異なります。この図は、あくまで依存関係が存在し得ることを示す一例として見てください。
重要なのは、業務上もっとも重要なシステムが、技術的にも必ず最初に復旧できるとは限らない、という点です。
3つの考え方の整理
ここまで見てきた3つの考え方を、簡単な表として整理します。
| 考え方 | 中心となる問い | 主な視点 | 何が影響するか | 自動的には決まらないもの |
|---|---|---|---|---|
| Business Criticality | 業務上どれだけ重要か | 業務・組織の視点 | 中断時の影響（Chapter 4のBIA） | Recovery Priorityやその順序を自動的に確定するものではない |
| Recovery Priority | 何を優先して復旧したいか | 組織としての希望・判断 | Business Criticalityなど | Technical Recovery Orderと必ず一致するとは限らない |
| Technical Recovery Order | 実際にどの順番で復旧できるか | 技術・依存関係の視点 | システム間の依存関係 | 業務上の優先度をそのまま反映するとは限らない |
この表もあくまで整理のための目安であり、数値化されたスコアや優先順位を機械的に決める計算式ではありません。
6.6 依存関係を把握する意味
ここまで見てきたように、Technical Recovery Orderは、依存関係によって制約されます。
このことから言えるのは、復旧計画を考えるうえで、どのシステムがどの仕組みに依存しているかという情報を、あらかじめ把握しておくことが重要だということです。
依存関係の情報は、図やマップのような形で可視化しておくと、実際の復旧順序を検討する際に役立ちます。
ただし、依存関係をどのように整理するかという詳しい方法や、依存関係を洗い出すための体系的な方法論については、この章では扱いません。
6.7 まとめ
この章では、Business Criticality、Recovery Priority、Technical Recovery Orderという3つの考え方を整理しました。
重要なのは、次の点です。
- Business Criticality（業務上の重要度）、Recovery Priority（復旧の優先度）、Technical Recovery Order（技術的な復旧順序）は、それぞれ異なる観点である。
- Business CriticalityはRecovery Priorityに影響するが、Technical Recovery Orderを自動的に決めるわけではない。
- Technical Recovery Orderは、依存関係によって制約されることがある。
- 業務上もっとも重要なシステムであっても、技術的な依存関係のために、最初に復旧できるとは限らない。
- 依存関係の情報をあらかじめ把握しておくことが、復旧順序を検討するうえで重要になる。
次の章では、Backupやコピーをどのように配置し、分散させるかという、3-2-1という考え方とFailure Domainについて見ていきます。
Chapter 6を読み終えた時点で考えてみてください
自分が担当しているシステムについて、次の質問に答えられるでしょうか。
- Business CriticalityとRecovery Priorityは同じ意味でしょうか。
- Recovery PriorityとTechnical Recovery Orderが一致しないことがあるのは、なぜでしょうか。
- 業務上もっとも重要なアプリケーションを、最初に復旧できない場合があるのはなぜでしょうか。
- 技術的な依存関係が復旧順序を制約する例を、自分の言葉で説明できますか。
- この章で依存関係マッピングの詳しい方法まで扱わなかったのはなぜだと思いますか。
すべて答えられなくても問題ありません。
むしろ、答えに詰まった点があれば、それがこの章で確認しておくべきポイントです。