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つの落とし穴とその解決策を解説する。