ディザスタリカバリ計画のファンダメンタルズ：テストの基礎的要件
災害復旧計画を策定する前に、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
-
事例
なぜワンキャリアは障害復旧を3時間から1時間以内に短縮できたのか -
製品資料
自社のDevSecOpsはどこまで進んでいる？ 進捗を測る指針“成熟度モデル”とは -
製品資料
実際に悪用される脆弱性は4％前後 優先的に対処すべき脆弱性を把握するには？ -
事例
三菱ケミカルが脆弱性への迅速な対応フローを実現した方法とは？ -
技術文書・技術解説
MDMだけでは防げない？ Appleデバイスに潜む5つのセキュリティギャップ
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
IT人材の42％が転職予備軍 辞めさせない組織の4つの共通
-
2
「業務改善とツール活用」に関するアンケート
-
3
「HDD終了」は本当か 巨大クラウド2社が下した大容量フラッシュへの決断
-
4
契約作成からKYCまでAIが完結 独金融大手が3000人を削減してまで狙う破壊的効率化
-
5
LLMの「過学習」、正しく説明している文章はどれ？
-
6
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
7
AI投資が無駄に終わる 「データセンター人材の枯渇」が招く最悪のシナリオ
-
8
【漫画付き】"RAG導入失敗3例"と処方箋 「入れても使われない」を終わらせる
-
9
GitHub Copilotを使いこなす第一歩 初めてのプロンプト6つのコツ
-
10
ただで使い「12時間以内の復旧」を迫る 無償OSSを商用扱いする日本企業の末路
ホワイトペーパーランキング PR
-
1
属人化や仕様バグはなぜ起きる？ AI時代に必須のドキュメント文化の作り方
-
2
「NAS」「SAN」「DAS」は何が違う？ いまさら聞けないストレージの基礎
-
3
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
4
財務を戦略的組織へ進化させるAI活用術、4つの主要な障壁と解消方法
-
5
中小企業必見、Microsoft 365でゼロトラストセキュリティを実現する方法
-
6
セキュリティソフトをすり抜ける標的型攻撃メール、不審メールの見破り方とは？
-
7
“あのファイル転送”で暗躍するノーウェアランサム
-
8
5分で分かる「AI駆動開発エージェント」 要件定義から設計・実装・テストまで
-
9
動画で知るランサムウェア被害企業のリアル、会計データが無事だった理由とは
-
10
マンガで解説：「ゼロトラスト」「SASE」の必要性とメリット
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー