企業の災害復旧計画に必要なものと不要なもの（後編）

ディザスタリカバリ計画のカギは「自動化」にあり

ITコンポーネントの高機能化が進んだことで、復旧プロセスの多くの要素を自動化できるようになった。その場合、設定の詳細や復旧手順などを文書化することはさほど重要ではなくなる。

公開 2011年04月08日 09時00分

更新 2012年09月04日 15時45分

著者

Pierre Dorion

[TechTarget]

印刷する

　前編「ディザスタリカバリ計画の最優先事項は『ネットワークの復旧』」では、各社がディザスタリカバリ（DR）計画に文書化しておくべき優先事項を紹介した。本稿では、DR計画に含むべきではない項目を紹介する。

企業のDR計画に含めるべきでないものは？

　企業のDR計画には、含めるべきではないものもある。そうした項目をDR計画に含めても、余計な保守作業や混乱をもたらすだけだからだ。以下にその例を幾つか挙げる。

OSとアプリケーションのインストールに関する文書

　既に述べた通り、大切なのはサイト固有の設定だ。WindowsやOracleのインストールマニュアルを書き写しても何の意味もない

電話連絡網や緊急時の連絡先リストはできれば除外する

　こうしたリストは変更が頻繁なため、ひどく保守の手間が掛かるからだ。代わりに、小規模企業であれば、携帯電話の電話帳を丸ごと保存しておくといい。大規模な組織であれば、緊急時通報サービスの利用を検討する必要がある。問題の発生を知らせるために500人や1000人もの従業員に電話することなどできないからだ。

必要不可欠ではないシステムの災害復旧手順については、DR計画に文書化すべきではない

　計画が大きくなり、保守が難しくなるからだ。一般的に、さほど重要でないシステムは復旧も容易だ。なぜなら、その時点では既に他のITコンポーネントは通常の状態に戻っているからだ。そうした二次的なシステムに関するサイト固有の設定情報は、他の場所（オフサイトや電子メディアなど）に保存し、DR計画の中で参照させ、必要になった際にアクセスできるようにしておけばいい。ただし、その時点では既に災害復旧作業というより、システム再構築の作業になっているはずだ。だからこそ、こうした手順はDR計画の本体から除外しておくべきなのだ。

企業のDR計画のカギは「自動化」

　ITコンポーネントの高機能化が進み、今では復旧プロセスの多くの要素を自動化できるようになっている。その場合、設定の詳細を文書化したり、あるいは復旧手順を文書化したりすること自体がさほど重要でなくなる。

　以下に挙げたような項目に関しては、設定ファイルを作成してオフサイトに保存し、代替端末にアップロードして、環境を以前の状態に復元するという一連の作業を自動化できる（ただし、その多くはリカバリサイトに同一の機器があることを想定している）。

自動化できる作業

SANファブリックのゾーニング
ファイアウォールのルール
ネットワークスイッチの設定
仮想環境におけるシステムイメージ
ストレージアレイの設定
認証サービスとネームサービス（Active Directory）

データ複製とフェイルオーバーを活用する

　最後にもう1つ付け加えておきたいのは、最近では、物理的あるいは仮想的なサーバ環境で利用する、手ごろなデータ複製とフェイルオーバーの選択肢が増えつつあるという点だ。この点だけでも十分に大きなテーマだが、オフサイトでのデータ複製機能やフェイルオーバー機能を搭載しているITインフラは、「ゼロから復旧しなければならない環境と比べて、用意すべき文書や詳細な災害復旧手順がはるかに少なくて済む」ことを強調したい。

　ここまで述べてきたように、ITスタッフは「自動化」や「仮想化」「データ複製」「フェイルオーバー」などの技術を活用することで、復旧作業を推進するために必要な情報だけを含んだ軽量かつ保守が容易なDR計画の作成に集中できる。

本稿筆者のピエール・ドリオン氏は米アリゾナ州フェニックスのLong View Systemsでデータセンター担当のプラクティスディレクター兼上級コンサルタントを務め、事業継続性、災害復旧計画サービス、企業データ保護などを専門としている。

印刷する