5. 効率的な災害復旧インフラを設計する

　災害復旧インフラストラクチャは、ビジネスインパクト分析の要求定義とサービスレベルの目標をサポートしなければならない。災害復旧は日常の復旧機能を拡張したものだが、物理的な距離や帯域幅といった要素も考慮に入れる必要がある。ただ、アーキテクトや設計者にとって、ここ数年、リモート復旧オプションが劇的に拡大したのは朗報だ。従来のストレージミラーリングやレプリケーションは、幅広いレンジのシステムで利用可能になった。また圧縮やデデュプリケーション技術を利用すれば、必要な帯域幅を大幅に減らすことができる。加えて、サーバ仮想化などの技術もリモート復旧機能を劇的に向上させつつある。

6. 適切なターゲット復旧サイトを選択する

　災害復旧サイトの選択は、しばしば難しい挑戦になる。複数のデータセンターを運営する組織であれば、クロスサイト復旧機能を構築することが可能だろう。そうしたオプションがなければ、DRサイトの選択は、災害復旧を立案する上で最大の課題になる。検討すべき主なテーマは、必要な保護レベルと、災害復旧を社内で行うか、それともアウトソースするか（その場合はどの範囲までをアウトソースするか）である。

　ここで考慮しなければならない2つの要素は、リスクと利便性だ。これらは最も重要で、しばしば対立する要素でもある。地域的な災害に対する備えは、ITスタッフを収容する複数のDRサイトを本社から遠く離れた場所に設置することが肝要だ。サイトをホット、ウォーム、あるいはコールドのいずれにするかは、サービス復旧レベルによって決まる。その決定は極めてクリティカルだ。どのタイプのサイトにするかによって、固定費が大きく違ってくるからだ。一般的に、RTOを1日以下にするためにはホットサイトが必要になる。アウトソーシングについては、コントロール可能な範囲、可用性の保証、そしてもちろん、コストが大きなポイントになる。

7. 成熟した運用管理を確立する

　災害復旧を向上させる最良の方法はプロダクションの向上にある、と指摘する声は少なくない。言い換えれば、日常の運用がきちんと行われていなければ、災害復旧計画など意味を成さないというわけだ。すなわち、運用管理こそが災害復旧の最も本質的要素なのだ。運用管理の問題は、重要なプロセスに関するドキュメンテーションの欠落から発生する。災害復旧は定義上、最適下限条件を下回った危機的状況において始まる。そのため、厳密に記述された標準の運用手順を定義しておくことが不可欠だ。ITILなどの標準フレームワークに取り組んでいる組織は、災害時のカオス的状況にあっても混乱することなく災害復旧に着手できるだろう。

8. 現実的なテスト手法を開発する

　災害復旧テストは、運用を中断しなければならないなど実現が困難だったり、あるいはコストなどの制約から、テストといっても実行が容易なコンポートネントばかりに偏りがちだ。しかし、実際的なテストには、現実のビジネス機能の復旧テストを欠くわけにはいかない。コンポーネントのテストを定期的に行うことは当然だが、相互運用性や相互依存性の問題を念頭に置いた大規模な機能復旧テストも同様に重要だ。実際のプロダクション環境に近づけることができればできるほど、災害復旧機能もより「実証可能」となる。

　ここで取り上げたことは、いずれもITインフラの領域を超える。しかし、災害復旧に関する戦略的な意思決定が可能となるように、IT管理者は手元の問題を強く認識し、それらを解決する方法を学ばなければならない。それらは必ず、コントロール不可能な問題を解決しなければならない状況を避けることに役立つはずだ。