テストしていないDR（災害復旧）計画がもたらす残念な結末

iStock.com/fergregory

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

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

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

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

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

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

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

　大企業ならば、

・保護対象のアプリケーション
・その復旧方法
・復旧対応を代行できる人員の手配
など、計画をもっと細部まで練り込むことになる。こうしたDR計画としては、IBMの例を参照してほしい。

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

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

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

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