ディザスタリカバリ、対応時の現実とは？：続・ディザスタリカバリで強い企業を作る（4/4 ページ）

[小川晋平，ITmedia]

フェイルオーバー作業で見落としがちなポイント

●ステークホルダーの整理と内外への情報開示

　読者の企業／団体を取り巻くステークホルダー（利害関係者）には、どういった企業、団体、個人があるだろうか？　従業員、役員、株主、取り引き先、消費者など、いろいろなステークホルダーが考えられるだろう。

　信用の上にビジネスは成り立つが、その信用を成り立たせる重要な姿勢として、適時適切な情報開示がある。災害が起きた時こそ、この情報開示のスピードと内容は重要だ。この対応を適切に行うことができれば、災害対策が一通り終わった後、ステークホルダーから高く評価されるという付加価値を得ることができる。

　また、従業員にとっても、会社自体が今後どうなるのかは大きな心配ごとになる。会社の重要なリソースである人材に安心感を与え、復旧に向けてベクトルを合わせていくことも重要であろう。

　このように、有事の際には適時、適切な情報開示を行う必要がある。まずは、通常時から、いざというときどのステークホルダーにどのような情報を開示するかというルールを考えておく姿勢が必要である。あらかじめステークホルダーを整理し、それぞれに向けた情報開示の対策を考えておくとよい。

●被災していない拠点へのフォロー

　被災していない拠点ではプライマリサイトの情報システムが利用不可能となるため、業務の停滞が考えられる。また、プライマリサイト側のヘルプデスクも同様に被災している可能性が高く、一方DRサイト側ではフェイルオーバー作業にかかりきりになることも考えられる。こうなると、被災していない他の拠点では、いったい何が起きているのか不安になることが考えられる。

　そのため、大規模災害が起きた場合には、関連情報を公開するイントラネット掲示板をDRサイトに設置し、他拠点からはそれを参照してもらうようなルールを決めておくなど、何らかの情報開示手段を用意しておくとよい。

●問い合わせの抑制

　前述の通り、DRサイトはフェイルオーバー作業に忙殺され、プライマリサイトのヘルプデスクが機能していないと、「今いったい何が起きているのか」「電子メールはいつ復旧するのか」といった情報が知りたくなるだろう。こうした、業務の復旧上必要な情報は、被災していない拠点のフォローと同様に、DRサイトに設置するイントラネット掲示板を活用するなどして、積極的に開示していく。それによって問い合わせに関するコール数を減らし、ひいては本来実施したい作業に専念することができる。結果としてDRサイト側での早期のサービス復旧が可能となる。

●保守が通常のサービスレベルで機能すると思わない

　災害が起きた際に、ハードウェアが障害を受ける可能性はあるだろう。プライマリサイトに近い位置にDRサイトがある場合には保守拠点に注意したい。運用人員配置上、プライマリサイトとDRサイトが近いことはいいことなのだが、一方で、双方とも同じ保守拠点を使っている場合もある。この場合は必要なパーツが揃わない可能性もある。

　また、例えば東京と大阪のように保守拠点が離れている場合でも、大阪の保守拠点から応援にいくケースも考えられる。このため、通常契約している保守のサービスレベルを確保できるとは限らないことを受容しなければならない。

　対応策として、例えばスペアのハードディスクを多めに確保しておき、ディスク故障時の調達遅延リスクを回避するといったことをあらかじめ考えておくべきである。

●縮退系の増強

　プライマリサイトの復旧に時間がかかると考えられる場合には、DRサイト側において縮退系で構築しているシステムを増強する必要がある。もちろん増強をするかどうするかは、プライマリサイトの復旧までの見通し次第で考えればよい。

　ただし、災害直後はハードウェアの確保が難しいことも考えられるので、しばらくサービスレベルが落ちることを全社的に許容してもらえるよう、あらかじめ説明をしておいた方がよい。

元システムへのフェイルバック

●逆同期作業は実は大変

　プライマリサイトが無事復旧すれば、今後は逆同期を行い、DRサイト側で提供しているサービスの計画停止を行ってプライマリサイトにフェイルバックを行う。

　このときの逆同期であるが、プライマリサイト側のストレージが破壊されていた場合には、初期同期から行う必要がある。以前の記事で触れたように、大容量のデータを扱うサービスの場合、初期同期には非常に時間がかかる。このため、ひとたびフェイルオーバーを行うとフェイルバックはそうそう簡単にはできないということを改めて実感できると思う。

●Active Directoryに潜む危険

　MicrosoftのActive Directoryは便利であるが、Microsoft製品との結びつきが強すぎる。このため、プライマリサイト側で提供しているサービスに対してDRサイト側を追加する際、プライマリサイトのサービスを停止しなければDRサイト側でインストールできないという問題点がある。マイクロソフトのExchange Serverが典型的な例である。

　もし、両サイトで同一の名前でサービスが上がってしまうと、Active Directory自体に障害が発生することもある。このため、Active Directoryを利用する場合は設計にあたって細心の注意が必要だ。