Backupは存在します。
Recoveryを始めるための経路も、すでに確保されています。
業務側は、最も重要なApplicationから真っ先に戻してほしいと考えています。
しかし、そのApplicationは、まだ復旧できていない別の技術要素に依存しています。
ここで問題になります。
「業務上の優先順位と、技術的に実行可能なRecovery順序が一致しないとき、何を基準にPlanを組み立てればよいのか。」
この章では、この問いについて考えていきます。
14.1 Recovery Sequenceを考える必要がある
Chapter 12では、Recoveryが依存要素の問題であることを見ました。Chapter 13では、通常の管理経路が使えない状態からRecoveryを始めるための経路について考えました。
この章では、Recoveryを始められる状態になった後、実際にどのような順序でRecoveryを進めるかを考えます。
Recovery対象が一つだけであれば、順序について悩む必要はあまりありません。しかし、Recovery対象が複数あり、段階的に戻す必要がある場合には、「何を、どの順序で戻すか」という問題が生じます。
14.2 Business Priority ≠ Technical Recovery Order
業務側から見れば、最も重要なサービスを最初に戻してほしいと考えるのは自然なことです。
しかし、実際に技術的に実行できる順序は、必ずしも業務上の優先順位どおりにはなりません。
Business Criticalityは、Recovery Priorityに影響を与え得ますが、それがそのままTechnical Recovery Orderを自動的に決めるわけではありません。
この本では、この関係を次のように整理します。
Business Priority ≠ Technical Recovery Order
これは、この本での理解を助けるための整理であり、NISTやCISAが定めた標準的なルールではありません。
技術的な依存関係により、業務上はあまり目立たない基盤的な要素を、業務上重要なApplicationよりも先に戻す必要が生じる場合があります。例えば、業務上最優先のApplicationがDatabaseに依存しているなら、Applicationを先に戻したくても、Database側のRecoveryが先に必要になる場合があります。
これは、あくまで一つの仮定的な例です。実際にどのような依存関係が存在するかは、対象となるシステムによって異なります。
14.3 DependencyがRecovery順序を制約する
Chapter 12で見たように、Recoveryはさまざまな依存要素に左右されます。この依存関係の情報は、単に把握しておくだけでなく、図やマップのような形で維持しておくことも考えられます。それは、依存関係がRecoveryの順序に影響を与えるためです。
依存関係を把握しておくことで、「このサービスを戻すには、先に何が必要か」を考える材料が得られます。ただし、この章でChapter 12の依存要素の一覧を改めて示すことはしません。identity、DNS、network、storageといった個々の要素について、ここで再び説明することもしません。
ここで重要なのは、依存関係がRecovery順序に影響を与え得るという考え方そのものです。
14.4 一つの固定順序では決められない
ここまでの内容から、次のように考えたくなるかもしれません。
「それなら、依存関係だけを基準にすれば、正しいRecovery順序が自動的に決まるのではないか。」
しかし、この本ではそのようには考えません。
Recovery Priorityと、依存関係に基づくTechnical Recovery Orderは、関連してはいますが、同じものではありません。技術的な依存関係だけで、すべての状況に共通する一つの正しい順序が決まるわけでもありません。
そのため、この本では、次のような固定的なルールは支持しません。
- Identityを必ず最初に復旧しなければならない
- DNSを必ず最初に復旧しなければならない
- Storageを必ず最初に復旧しなければならない
- あらゆる組織に共通する、単一の正しいRecovery順序が存在する
実際の順序は、業務上の優先順位と、技術的な依存関係の両方を踏まえながら、その時々の状況に応じて考える必要があります。
14.5 Recovery PlanはRestore Commandの一覧ではない
ここまで、Recoveryの「順序」について考えてきました。次に、その順序を含めて、Recoveryの内容をどのように残しておくかを考えます。
Recovery Planは、単なるRestore Commandの一覧ではありません。
Recovery Planには、少なくとも次のような要素を考慮しておく必要があります。
- 人（people）
- プロセス（process）
- 技術（technology）
- 外部リソース（external resources）
- 依存要素（dependencies）
コマンドを実行する手順だけを書き残しても、それを実際に動かす人や、必要なプロセス、外部の協力先、依存している他の要素が考慮されていなければ、実際のRecoveryでは不十分になる場合があります。
14.6 Playbookに残すべき情報
Recoveryを実際に進めるための情報を整理するものとして、この本ではPlaybookについても扱います。
Playbookには、少なくとも次のような情報を残しておくことが望ましいと考えられます。
- 実行可能な処理（actionable processes）
- 責任者（responsible personnel）
- 発動条件・権限（invocation conditions / authority）
- 通知経路（notification paths）
- マイルストーン（milestones）
- 完了基準（completion criteria）
これに加えて、前の節で見た依存要素や外部リソースについても、Playbookの中で扱っておくことが考えられます。
対象となるシステムやサービスごとに、こうした情報を整理しておくことで、実際のRecoveryを進めやすくなります。
これらの情報を、簡単な表として整理してみます。
| 対象 / 処理 | 責任者 | 発動条件・権限 | 通知経路 | 依存要素 | 外部リソース | マイルストーン | 完了基準 |
|---|---|---|---|---|---|---|---|
| （例：あるサービスのRecovery） | 誰が実行するか | どのような条件・権限で始めるか | 誰に、どう伝えるか | 何に依存しているか | 外部の協力先や資材 | 途中の区切り | 何をもって完了とするか |
この表は、Playbookに残しておくとよい情報を整理するための、この本の一つの例にすぎません。特定の標準機関が定めた公式のテンプレートというわけではなく、「対象 / 処理」の列も、情報を整理するための便宜的な区分です。実際の形式は、組織や対象によって異なります。
14.7 Completion Criteriaと次章への接続
Playbookに残しておくべき情報の一つとして、完了基準（completion criteria）があります。
あるRecoveryの作業を「行った」ことと、その作業が実際に「完了した」ことは、同じではありません。何らかの操作を試みたというだけでは、それが完了したとは言えない場合があります。Playbookには、何をもって完了と見なすかを、あらかじめ明確にしておく必要があります。
また、データの復元、システムの復旧、サービスの復旧、業務の再開は、それぞれ異なる確認結果を表します。あるレベルで「戻った」ことが、別のレベルでも自動的に「戻った」ことを意味するとは限りません。
ただし、これらをどのように具体的に検証するか、どのようなテストや演習を通じて確認するかについては、この章では扱いません。それは、後の章で改めて扱います。
14.8 まとめ
この章では、Recoveryをどのような順序で進めるか、そしてその内容をどのように残しておくかについて整理しました。
重要なのは、次の点です。
- 業務上の重要性（Business Priority）と、技術的に実行可能なRecovery順序（Technical Recovery Order）は、同じではない（Business Priority ≠ Technical Recovery Order）。
- 技術的な依存関係は、業務上目立たない要素を先に戻す必要を生む場合がある。
- 依存関係だけでも、業務上の優先順位だけでも、一つの正しいRecovery順序が自動的に決まるわけではない。
- Recovery Planは、Restore Commandの一覧ではなく、人・プロセス・技術・外部リソース・依存要素を考慮する必要がある。
- Playbookには、責任者、発動条件・権限、通知経路、マイルストーン、完了基準などの情報を残しておくことが望ましい。
- 完了基準を明示しておくことで、「行った」ことと「完了した」ことを区別できる。
Chapter 14を読み終えた時点で考えてみてください
自分が担当しているシステムについて、次の質問に答えられるでしょうか。
- Business PriorityとTechnical Recovery Orderは、なぜ同じものではないのでしょうか。
- 業務上重要なApplicationを最初に戻したくても、そうできない場合があるのはなぜでしょうか。
- なぜ本書では一つのRecovery順序を標準として提示しないのでしょうか。
- Recovery PlanがRestore Commandの一覧だけでは不十分なのはなぜでしょうか。
- PlaybookでCompletion Criteriaを明示する意味は何でしょうか。
すべて答えられなくても問題ありません。
むしろ、答えに詰まった点があれば、それがこの章で確認しておくべきポイントです。