ある組織では、多数の業務システムについて、日々Backupを取得していました。
ある日、障害が発生しました。技術的には、複数のシステムのBackupが利用可能な状態でした。
しかし、いざ復旧を始めようとしたとき、担当者たちは次のことに気づきました。
- どのシステムから復旧すべきか
- どの業務を先に戻すべきか
- 何が止まると、最も大きな影響が出るのか
これらが、あらかじめ整理されていなかったのです。
システムごとに、業務への影響の大きさは大きく違っていました。しかし、それに気づいたのは、まさにその復旧作業の最中でした。
「Backupがあること」と、「何を優先してRecoveryすべきかが分かっていること」は、別の問題です。
この章では、技術的なBackupやRecoveryの設計に入る前に、まず何を、どこまで守る必要があるのかを考える出発点について見ていきます。
4.1 技術設計の前に考えること
これまで、Backupが存在することと、必要なときにRecoveryできることは別だと見てきました。
では、そもそも何を優先してRecoveryできるようにする必要があるのでしょうか。
技術的な方式を選ぶ前に、まず業務上何が重要かを理解し、中断したときの影響を見て、そこからRecoveryの必要性を考える、という順序があります。
Chapter 3ではBackup方式とRestore dependencyを見ました。しかし、方式を選ぶ前に、どの業務やデータを優先して守る必要があるかを考える必要があります。
この章では、その出発点となる考え方を扱います。これは、すべての状況に当てはまる固定的な手順というより、設計を始める前に踏まえておきたい考え方の流れとして紹介するものです。
4.2 BIAとは何を見るものか
BIA（Business Impact Analysis、業務影響分析）は、業務や機能が中断したときに、どのような影響が生じるかを分析する取り組みです。
米国国立標準技術研究所、NIST（National Institute of Standards and Technology）が公開している情報システムの復旧計画に関する技術文書（Contingency Planning Guide for Federal Information Systems）でも、BIAは、業務・機能の分析、中断による影響、復旧の必要性、そして復旧の優先順位を考えるための基礎情報を提供するものとして扱われています。
ここで誤解しやすい点を整理しておきます。BIAは、次のようなものではありません。
- Backup対象の一覧を作る作業そのもの
- IT資産の棚卸だけを行う作業
- risk assessment（脅威やリスクそのものの評価）そのもの
- Recovery architectureを一意に決める作業
BIAが提供するのは、後続の計画づくりで使う材料です。BIA自体が、技術的な設計や具体的な手順を決めるわけではありません。
4.3 業務機能と中断影響を見る
BIAでは、まず組織が行っている業務や機能を洗い出し、それぞれが停止したときにどのような影響が生じるかを考えます。
例えば、次のような違いが考えられます。
- 停止しても、比較的短期間であれば影響が小さい業務
- 停止すると、他の業務にも影響が連鎖する業務
- 停止すると、外部の顧客や取引先に直接影響する業務
- 法令、契約、安全などに関係する業務
これらはあくまで、業務影響の違いを理解するための例示です。すべての業務がこの4つのどれかに必ず当てはまる、という固定的な分類ではありません。
重要なのは、「同じように見える業務でも、止まったときの影響は同じではない」という視点を持つことです。この視点が、次の4.4につながります。
4.4 すべてを同じ優先度では扱えない
ここまで見てきたように、業務ごとに中断時の影響は異なります。
このことから言えるのは、すべてのシステムやデータを、同じ条件・同じ優先度でRecoveryする必要があるとは限らない、ということです。
冒頭のシナリオで担当者が直面したのも、まさにこの問題でした。技術的にはBackupが揃っていても、どれを優先して戻すべきかが整理されていなければ、復旧時の判断や優先順位付けが難しくなります。
ここで一つ、注意しておきたいことがあります。「業務影響が大きいものから優先して戻す」という考え方と、「技術的にどの順序で戻せるか」という話は、必ずしも同じではありません。例えば、ある業務が非常に重要であっても、その業務を支える基盤的な仕組みが先に復旧していなければ、その業務自体を戻すことはできない場合があります。
この、業務上の優先度と技術的な復旧順序の関係については、後の章で改めて詳しく扱います。この章では、「業務影響によって必要なRecoveryの内容や緊急度が変わり得る」という基礎の部分までを扱います。
4.5 Recoveryに必要なresourceを考える
BIAによって、どの業務が重要で、中断するとどのような影響があるかが見えてきたら、次に考えたいのは、その業務を実際にRecoveryするために何が必要か、という点です。
ここで押さえておきたいのは、Recoveryに必要なものは、Backup dataだけではない、ということです。
例えば、次のようなものが関係することがあります。
- 実際に復旧作業を行う人
- 復旧のための手順
- 復旧に使うシステムや技術
- 外部のサービスや取引先など、組織の外にあるリソース
- 復旧作業を行うための施設や設備
これらはあくまで一例であり、すべての組織・すべてのシステムで必ずこの通りに当てはまる、決まったリソース一覧ではありません。
大切なのは、Recovery planningでは、必要な組織リソースが何かを識別し、それらの優先順位を考える必要がある、という点です。Backup dataさえあれば復旧作業全体が成立する、というわけではありません。
ここまでの整理
ここまでBIAで見てきた内容を、簡単な表として整理します。
| 見る対象 | 確認すること | なぜRecovery設計に関係するか |
|---|---|---|
| 業務機能 | どのような業務・機能があるか | 何を守る対象とするかの出発点になる |
| 中断時の影響 | 停止したときにどのような影響が生じるか | 業務ごとの重要度・緊急度の違いを把握する材料になる |
| 必要なresource | 復旧にどのような人・手順・技術・外部リソースが関係するか | Backup dataだけでは復旧が完結しないことを踏まえた計画の材料になる |
| 復旧の必要性 | どの業務・機能を、どの程度優先して復旧する必要があるか | 後続のRecovery requirement・優先順位の基礎になる |
この表もあくまで整理の目安であり、重要度を数値化したスコアや、優先順位を機械的に決める計算式ではありません。
4.6 BIAから分かること、分からないこと
ここまでの内容を整理すると、BIAは、業務機能、中断時の影響、復旧の必要性、そして優先順位を考えるための基礎情報を与えてくれます。
一方で、BIA単体では決まらないことも、はっきりさせておく必要があります。BIAだけでは、次のようなことは決まりません。
- 具体的にどのBackup製品を使うか
- Full / Incremental / Differentialのどれを選ぶか
- 具体的なRecovery architecture（技術構成）
- 実際の技術的な復旧順序
- RTO・RPOなどの具体的な目標値のすべて
BIAで得られる情報は、こうした後続の判断のための材料や基礎になるものであり、それ自体が答えを一意に決めるわけではありません。具体的な時間目標や許容できるデータ損失の範囲については、次のChapter 5で扱います。
4.7 Backup / Recovery設計へのつなぎ方
この章で見てきた考え方の流れを、簡単に整理すると次のようになります。
Teaching Diagram（簡略化した概念図であり、BIAだけでRecovery設計が一意に決まることを
示すものではありません）
Business / Mission Function（業務・機能）
↓
Disruption Impact（中断時の影響）
↓
Recovery Requirementの基礎（復旧の必要性・優先度の材料）
↓
Backup / Recovery設計の入力この図が示しているのは、業務機能から中断影響、復旧の必要性という流れが、最終的にBackupやRecovery設計を考えるための入力になる、ということです。
ここで強調しておきたいのは、この流れが業務影響からBackup/Recovery設計の内容を自動的に、一意に決めるわけではないという点です。BIAで得た情報は、判断のための材料であり、基礎になるものです。実際の設計では、この章より後の章で扱う技術的な観点も合わせて考える必要があります。
実際のRecovery planでは、Backupデータだけでなく、人、手順、技術、外部リソースや依存関係も考える必要があります。Recovery planそのものについては、後の章で改めて扱います。
4.8 まとめ
この章では、技術的なBackup設計に入る前に、業務影響と復旧要求を確認する必要があることを整理しました。
重要なのは、次の点です。
- BIAは、業務機能、中断時の影響、復旧の必要性、優先順位を考えるための基礎情報を提供する。
- BIAは、Backup対象一覧の作成やIT資産の棚卸そのもの、risk assessmentそのものではない。
- すべてのシステムやデータを、同じ条件・同じ優先度でRecoveryする必要があるとは限らない。
- Recoveryに必要なものはBackup dataだけではなく、人、手順、技術、外部リソースなども関係する。
- BIAだけでは、具体的な製品選定、Backup方式、Recovery architecture、技術的な復旧順序、RTO/RPOの具体的な値は決まらない。
次のChapter 5では、RTO（目標復旧時間）とRPO（目標復旧時点）について、具体的にどのように考えるかを見ていきます。
Chapter 4を読み終えた時点で考えてみてください
自分が担当しているシステムや業務について、次の質問に答えられるでしょうか。
- BIAをBackup製品選定より先に考える理由を説明できますか。
- 業務中断の影響を見ることが、Recovery設計にどう関係するか説明できますか。
- すべてのシステムを同じ優先度で扱う必要があるとは限らない理由を説明できますか。
- Recoveryに必要なものがBackup dataだけではない理由を説明できますか。
- BIAだけでは決められないことを説明できますか。
すべて答えられなくても問題ありません。
むしろ、答えに詰まった点があれば、それがこの章で確認しておくべきポイントです。