Chapter 15 — Restoreできた、では足りない

Restore作業が終わりました。

データは、確かに戻っているように見えます。

システムも起動しました。

しかし、想定していたサービスは、まだうまく使える状態になっていません。

ここで気づきます。

「Restoreが終わった」ことは、「Recoveryが成功した」ことをそのまま意味しない。

この章では、この違いについて考えていきます。

15.1 Restoreが終わっただけでは十分ではない

Chapter 14では、Playbookには完了基準（completion criteria）を残しておくべきだということを見ました。この章では、その完了基準が実際に満たされたと、どうやって確認できるのかを考えます。

Backupの復元操作そのものが成功したというだけでは、Recoveryが成功したことを示したことにはなりません。Recoveryに関連するtestやexerciseは、実際に意図したRecoveryの結果が得られたかどうかを確認する必要があります。

Restoreできた ≠ Recoveryできた

この章では、この違いを整理していきます。

15.2 「何が戻ったのか」を分けて考える

「Recoveryが成功したかどうか」を一つの問いとしてまとめてしまうと、確認すべきことを見落としやすくなります。

そこでこの本では、Recoveryの成功を、正式な段階分けとしてではなく、「何が戻ったのか」を分けて考えるための整理として捉えます。

例えば、次のような問いは、それぞれ別のことを確認しています。

• Backupは作成されているか
• データはRestoreできたか
• システムは動作するか
• サービスは機能するか
• 複数のシステムにまたがる、あるいは業務としてのRecoveryはできているか
• 戻った状態は信頼できるか（trusted-state validation）

これらは、それぞれ異なる検証結果（verification outcomes）を表します。

この整理は、この本がここまでの複数の観点を組み合わせてまとめたものであり、NISTやCISAが定めた公式の階層や、標準的な6段階モデルではありません。

また、上のリストは説明のために並べたものであり、必ずこの順番どおりに一つずつ確認し終えなければ次に進めない、という意味でもありません。ある観点が確認できていなくても、別の観点について考え始めることはできますし、実際の状況によって、何から確認するかは変わり得ます。

15.3 Data / System / Service / Businessは同じ確認ではない

データが戻ったこと、システムが動作すること、サービスが機能すること、そして業務として実際に使えることは、それぞれ異なる確認です。

ファイルが戻ったことを確認できても、それだけでServiceが利用できることまでは確認できません。

同じように、システムが起動したという確認は、そのサービスが実際に機能することを自動的に証明しません。そして、サービスが技術的に機能しているという確認は、業務としてそのサービスを実際に使えることを自動的に証明しません。

技術的な確認が済んでいるからといって、業務側がそのまま利用できるとは限りません。逆に、業務側の要望が満たされているように見えても、技術的な確認が省略されてよいわけでもありません。それぞれが、別々に確認すべき事柄です。

15.4 Trusted-state validation

ここまでの「何が戻ったのか」という観点に加えて、もう一つ別の観点があります。

それは、戻った状態そのものが、信頼できる状態かどうかという問いです。

Chapter 11では、どのRecovery Pointを採用すべきか、そしてその状態が信頼できるかどうかをどう考えるかについて扱いました。この章では、その考え方を改めて詳しく扱うことはしません。

ここで確認しておきたいのは、trusted-state validationも、data・system・service・businessの確認とは別の確認観点だということです。技術的にシステムやサービスが動作していることが確認できても、それだけで、戻った状態が信頼できることまでは確認できません。

15.5 Completion Criteriaを実際に確認する

Chapter 14で見たように、Playbookには完了基準（completion criteria）を残しておくことが望ましいとされています。

完了基準とは、あるRecoveryの作業が完了したと見なすために、何が真でなければならないかを示すものです。

この章で考えたいのは、その条件が実際に満たされたと、どうやって確認するかという点です。ある作業を「行った」ことと、それが「完了した」ことは、同じではありません。単に何らかの操作を実行したというだけでは、完了基準を満たしたことにはなりません。

具体的にどのような手順や様式で確認・承認を行うかについては、この章では扱いません。

15.6 Tabletopで確認できること、できないこと

Recoveryの確認方法にも複数の種類があり、それぞれ異なる性質を確認します。ある方法で確認できたことを、別の方法で確認すべき性質まで自動的に広げることはできません。

Tabletop exerciseやfunctional exerciseを含むTest / Exerciseの違いと詳細は、次のChapter 16で扱います。

15.7 Test / Exerciseの詳細は次章へ

この章では、Recoveryの結果として「何が確認できたのか」を区別する考え方を中心に扱いました。

実際のRecoveryでも、事前のTestでも、何が確認できたのかを区別する必要があるという点は、共通しています。

一方で、tabletop exerciseやfunctional exerciseをどのように設計するか、どのような頻度で実施するか、確認結果をどのように改善につなげていくかといった内容については、この章では扱いません。それらは、後の章で改めて扱います。

15.8 まとめ

この章では、Restoreが終わったことと、Recoveryが成功したことは同じではないという考え方を整理しました。

重要なのは、次の点です。

• Backupの復元操作が成功しただけでは、Recoveryが成功したことを示したことにはならない（Restoreできた ≠ Recoveryできた）。
• 「何が戻ったのか」を、data・system・service・businessという異なる観点で分けて考える必要がある。それぞれの確認は、次の確認を自動的に証明しない。
• 戻った状態が信頼できるかどうか（trusted-state validation）も、別の確認観点である。
• 完了基準は、それが実際に満たされたことを確認して初めて意味を持つ。
• Tabletop exerciseの成功は、それだけでは技術的なRecoverabilityを証明しない。
• ここで示した整理は、この本独自の教材上の観点であり、NIST/CISAが定めた標準的な階層ではない。

この章で確認する代表的な観点

ここまでの内容を、簡単な表として整理します。

この表は、この本がRecoveryの確認観点を整理するための一つの教材であり、NISTの公式な検証マトリクスや、必ず満たすべき普遍的なチェックリストではありません。また、行の並びは説明のための順序であり、必ずこの順に一つずつ完了しなければならないという意味ではありません。ある行が確認できていなくても、他の行について考え始めることは可能です。

Chapter 15を読み終えた時点で考えてみてください

自分が担当しているシステムについて、次の質問に答えられるでしょうか。

1. Restoreが成功しただけでは、なぜRecovery成功とは言えないのでしょうか。
2. Data RestoreとService Recoveryは、何が違うのでしょうか。
3. Serviceが戻ったこととBusinessが利用できることは、なぜ同じではないのでしょうか。
4. この章で使った検証結果（verification outcomes）の整理が、NISTの標準的な階層ではないのはなぜでしょうか。
5. Tabletop exerciseが成功してもtechnical recoverabilityを証明したことにならないのはなぜでしょうか。

答えに詰まった項目があれば、どの確認観点を区別できていないかを見直してください。