テストしていないDR（災害復旧）計画がもたらす残念な結末：災害復旧が失敗する6つの落とし穴【前編】

さまざまな要因により、災害復旧の優先度が高まっている。だが多くの企業が、普通に考えれば落ちるはずのない落とし穴にはまって復旧に失敗している。この、当然回避できる落とし穴になぜ落ちるのか。

[Stephen Pritchard，Computer Weekly]

　災害復旧（DR）は、ITの障害や自然災害など予期せぬ事態が起きた後、「通常業務」に戻す機能である。

関連記事

• 仮想化時代のバックアップと災害復旧
• 徹底解説：Hyper-Vの災害復旧（DR）機能
• クラウドストレージかテープかを決める境界線
• テープの無視できないメリットと残念なデメリット
• 企業が絶対知っておくべきコンテナセキュリティの弱点

　中核ビジネスシステムのメンテナンス、そのシステムデータの保護、クライアントPCやネットワークの提供を担当するのはIT部門だ。最近では、音声通信の提供なども担当に含まれる。だがDR計画は事業規模の課題なので、事業部門にも責任が及ぶ。

　企業はかつてないほどデータを利用するようになっており、IT部門は世界中のどこでもそうしたデータへのアクセスを適切に提供するようになりつつある。こうした状況を背景に、IT部門にはこれまで以上に大量のデータの処理が求められる。ユーザーや顧客はダウンタイムに以前ほど寛容ではなくなっており、データに対する攻撃を企業の機能を停止させ金銭を得るための手段と考える攻撃者も増えている。

　ITサービスの継続性に関する国際規格であるISO 27031では、IT部門向けにDR計画の枠組みが定められている。

　だが事業運営とITシステム双方の複雑さが増しており、不用心な企業の落とし穴は増えている。

DRの落とし穴1：計画の怠り

　最大の失敗は、DR計画を怠っていることだ。

　複雑なDR計画は必要ない。小企業や支社であればあまり複雑な計画にはせず、オフサイトに保管されているストレージやクラウド（最近増加中）にデータを定期的にバックアップすること。最悪の事態が起きた際にデータにアクセスする方法とアプリケーションを復旧する方法を定める程度でいいだろう。

　大企業ならば、

• 保護対象のアプリケーション
• その復旧方法
• 復旧対応を代行できる人員の手配

など、計画をもっと細部まで練り込むことになる。こうしたDR計画としては、IBMの例を参照してほしい。

　Freeform Dynamicsでアナリストを務めるトニー・ロック氏によると、DR計画には各種プラットフォームの復旧順序を明記しておくべきだという。「アプリケーションやサービスの要件からこの順序が明確に決まることもある。だが、主要サイトの復旧が必要な場合は社内の政治力が影響するかもしれない。DR作業に着手できる人員や作業環境がどうなっているかも問題になる」と同氏は話す。

　DR計画を用意しても、その対象範囲を限定し過ぎると別の問題が発生する。つまり、IT部門や経営陣が誤った安心感を持つ恐れがある。このような場合、DR計画があったとしても全てのアプリケーションが網羅されておらず、極めて重要なアプリケーションの相互依存関係を見落とすことになる。

　IDCでアナリストを務めるフィル・グッドウィン氏は次のように語る。「DR計画で保護対象になっているアプリケーションはわずか38％程度だ。IT部門の大半はミッションクリティカルなアプリケーションのDR計画を用意しただけで、他のプロジェクトに取り掛かってしまう。その結果、ミッションクリティカルなアプリケーションは復旧できても、そのアプリケーションよりも重要度の低いアプリケーションのデータや接続が失われることがよくある。環境全体を迅速に立ち上げることもできない」

　計画では目標復旧時点（RPO）と目標復旧時間（RTO）も設定しておかなければならない。つまり、安定状態のクリーンなアプリケーションとデータのセットを手に入れるにはどの時点まで、どの程度の時間で戻す必要があるかを定める。

DRの落とし穴2：テストの怠り

　次の落とし穴はテストを怠ることだ。これは恐らく最も大きな落とし穴になる。よく引用される統計によると、IT部門の23％はDR計画を一度もテストしていないとされている。年に1回テストするのも29％程度だ。

　テストが年に1回で十分かどうかは事業の規模と性質に大きく左右される。だが、テストされない計画は無計画状態から一歩進んだにすぎない。

　「もう一つの大きな問題は、DRプロセスのテストに関係する。DR計画をテストするまでは、それが実際に機能するかどうかは分からない。保護対象のシステムが全て保護されているかどうかも確認できない。そのためテストは不可欠だ」とFreeform Dynamicsのロック氏は述べる。

　堅牢（けんろう）なテスト体制を確保するには、CIO（最高情報責任者）の強力なリーダーシップが必要だ。DR計画の効果的なテストは大変な作業になり、コストもかさむ可能性がある。だが災害から復旧できなければもっと高いコストがかかるだろう。

　「問題は、事業部門のユーザーや予算の管理者がテストの実施許可に消極的な場合があることだ」とロック氏は警告する。そのためIT部門のリーダーの強力な後押しが極めて重要になる。

　DR計画の未テストと密接に関係するのは、計画の更新を怠ることだ。DR計画は随時更新すべきドキュメントだ。成長、買収、業務プロセスの変化、技術の更新によって業務が変われば、DRの要件と手法も変わる。詳細な計画を立てても、保管したまま放置すれば効果はなくなるだろう。

　DR計画をテストすれば教訓が得られる。CIOはそこで学んだ教訓を生かしてDR計画を確実に更新する必要がある。さらに、更新したDR計画をテストする。こうしたサイクルを繰り返すことが欠かせない。

後編（Computer Weekly日本語版　3月18日号掲載予定）では、残る4つの落とし穴とその解決策を解説する。