ディザスタリカバリ計画のファンダメンタルズ：テストの基礎的要件
災害復旧計画を策定する前に、RTOとRPOを決定せよ
策定した災害復旧計画の妥当性を確認するために必要不可欠な要素。それは、災害復旧のプロセス全体を包括するテストだ。
災害復旧（DR）計画を成功させるために欠かせない基盤の1つが、事業の要求定義を理解することだ。会社が必要とするものは何か。そして機能とコストの観点から、それらのニーズに対応することは可能か？ そのパフォーマンスを図る重要な数値となるのが、目標復旧時間（RTO）と目標復旧地点（RPO）だ。簡単に説明すると、RTOはオペレーションを復活させるまで（データ復旧だけではない）の最長許容時間であり、RPOはデータ損失の最大許容範囲だ。
クリティカルなアプリケーションに対して、これらの数値を正しく理解し、関係者の間で合意できなければ、つまりそれらをサポートする環境への投資や開発に失敗すれば、業務部門とIT部門との間で災害復旧に対する認識に大きなギャップが生まれる。それを避けるためには、IT部門が業務部門やアプリケーションの所有者側と十分に議論し、彼らの復旧ニーズを正確に理解する必要がある。そうすることで、被災時の経済的損失を見極め、必要なサービスレベルを提供するためのコスト計算が可能になる。そのためにも、ここでは交渉力が不可欠だ。議論なくしてDRの成功はおぼつかない。
それらの手順は情報テクノロジーの範囲を超えるが、まずは計画立案、そして相互依存性の特定、プロセスの開発があり、それらを踏まえた上でしっかりとしたテストを行わなければならない。
計画の失敗は深刻な事態に
DR計画は、組織が被災したとき、いつ、どこで、何をすべきかを詳細に示すロードマップだ。そこには災害の前、災害の間、災害の後に実行すべきアクションが含まれる。また、災害であると判断する基準、被災を判定する責任者、その告知方法なども、基本的な要素として欠くことはできない。過去に起きたハリケーン関連の災害では、コミュニケーションの重要性が浮き彫りになった。優れた計画を立案するためには、例えば電子メールが機能しない、あるいは携帯電話サービスが利用できない、といった偶発的な事故もまた想定しておく必要がある。
プロセスと手順は文書化しておかなければならない。それは分かっている。しかし、ほとんどの人は文書化に後ろ向きだ。万全を期して慎重に作成されたDR計画であっても、適切な配慮に欠ければ無意味なものとなってしまう。システムを修正するときやソフトウェアにパッチを当てるとき、あるいは追加のストレージを割り当てるときなど、DR計画への影響を自動的に検討するように、災害復旧は標準の変更管理プロセスに組み込まれるべきだろう。同じように、組織再編が行われたときも、DR計画は再検討されなければならない。
データ量が2桁成長を続けていれば、いずれRTOの制約内でのデータ復旧が困難になることは明らかだ。しかし、アプリケーションの複雑性や相互依存性も、同様に復旧の大きな障害要因であるにもかかわらず、しばしば見過ごされがちだ。今日、メジャーなアプリケーションは複数のサーバやアーキテクチャにまたがって存在する。もはやメインフレームのアプリケーションがUNIXやWindowsプラットフォーム上に存在するアプリケーション、あるいはサブコンポーネントにデータを供給する時代ではない。伝統的なサーバ中心の復旧手法をベースとする場合、アプリケーションのコンポーネントごとにバックアップやスナップショットを取るのは可能だが、多様なコンポーネントにまたがる非一貫性を考えれば、アプリケーションを完全復旧するのは困難だ。
だが、アプリケーション間の相互依存性を理解し、適切なデータ保護アプローチを適用すれば、この問題を回避できる。その場合、独立したエレメントを包含する一貫性グループ機能を持ったスプリットミラー／レプリケーション技術や、継続的データ保護（CDP）技術などの手法を用いればよい。
テストなければ復旧なし
DR計画の立案は、計画をテストすることと比べたらそれほど困難ではない。DR計画のテストは、大抵は恐怖心を持って迎えられ、残念なことにしばしば回避されてしまう。テストを行わなくても計画の立案は可能だろう。だが、適切なテストを行わなければ、本番で成功する見込みはほとんどない。
災害復旧計画のテストで考慮すべきこと
- データの復旧だけではなく、アプリケーションの復旧もテストする（アプリケーションの相互依存性を確認する）
- 非専門家に復旧を行わせて、その手続きとドキュメンテーションを確認する
- 複数の災害シナリオを設定してロールプレイングを行う
- 災害復旧テストに対する前向きな思考態度を確立する：問題の発見と解決は効果的
- 改善点の効果測定およびグラフ化のために評価値を追跡する
本格的なテストを実行しない最も一般的な理由は「コスト」だ。この点が必ず争点になるのは、DRテストが日常業務の枠内に入らないとみられているためだ。この問題に対する唯一の効果的な解決策、すなわちコストを正当化する方法は、テストプロセスをRTO／RPOのサービスレベル目標に緊密にリンクさせることだ。それは災害復旧のビジネスケース（特にRTO／RPOの財務的効果）を正確に測定することを意味する。包括的なテストは、それらの評価基準が実際に適合するかどうかを確認するための基本的な要求であり、災害復旧プロセスに必要不可欠な要素なのだ。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か？ PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える？ 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣 -
製品資料
[サイボウズ株式会社] AIが「わざわざ使うツール」になっていない？ 業務で自然に使う導線にする秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか？ 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
ChatGPTは“検索しまくり”でGeminiは“淡泊”？ データが明かすAIの裏側
-
4
なぜ「Gemini 4 Argon」は出遅れたのか？ Googleが狙う“逆転のシナリオ”
-
5
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
-
6
損保ジャパンはなぜ「COBOL」を捨てなかったのか？ 脱メインフレームの真相
-
7
「Wi-Fi 7」経由でWindowsが乗っ取られる？ 最高権限奪取の恐怖
-
8
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
9
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
10
【漫画付き】ひとり情シス協会が明かす、RAG導入でしくじる企業「2つの共通点」
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化？ 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険？ 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化？ 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない？ 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ？
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー