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

[小川晋平，ITmedia]

フェイルオーバー宣言

　通信手段が限られる中で、可能な範囲で情報を収集したならば、それに基づいてフェイルオーバーを行うか否かを宣言することになる。連絡がうまく付かない場合を想定しながら、必要とあらば適切なタイミングでフェイルオーバーの実行を宣言することが重要だ。

●意思決定者と連絡がとれる場合

　災害対策本部のIT担当とDRサイト側でフェイルオーバー作業を行う担当者との間で連絡がとれる場合には、状況を踏まえた上で災害対策本部のIT担当がフェイルオーバー宣言を行うため問題はない。さらに、現地状況を確認できるIT担当者とも連絡が取れる場合は、フェイルオーバーの進言とともに、より詳しい情報を災害対策本部のIT担当に上げていく。

●DRサイト運用側での強制フェイルオーバー判断基準の明確化

　災害発生直後は、例えばなかなか災害対策本部が立ち上がらなかったり、現地を確認する役割を担っている担当者の誰とも連絡がつかないといったケースは十分考えられる。こんな場合は、事業継続上のサービスの復旧を優先し、災害対策本部のIT担当によるフェイルオーバー宣言がなされる前に、ある一定の条件を満たした段階で強制的にフェイルオーバーを実施することが必要になる場合もある。せっかくDRシステムを構築していても、意思決定を下す人がいないがために有事の際に使えない、というのでは意味がない。

　ただし、いったんフェイルオーバーを行うと、後戻りは簡単ではない。その後のフェイルバックは大規模な作業となり、多くの工数がかかる。したがって、プライマリサイトでのちょっとしたトラブルで簡単にフェイルオーバーの判断を下すと、思わぬコストがかかることになる。

　こうした要因を考えると、フェイルオーバーに関する意思決定は責任ある立場の人物が行うことが望ましい。通常は、役員クラスがその責を担う、災害対策本部のIT担当（情報システム担当役員が担うことが多い）が意思決定を行う形で業務設計を行うのが妥当である。

　強制フェイルオーバーとは、それだけ重要な意思決定を代行するものだ。したがってその判断基準は、明確かつ合理的理由があるものでなければならない。

　例えば、「被災していないすべての拠点からプライマリサイト側にアクセスできない」「災害対策本部に連絡を取り続けても半日以上連絡がつかない」「現地確認を行う担当者にも半日以上連絡がつかない」「TV、ラジオでは大規模な災害であるという客観的事実を報道している」といった条件が重なった場合に強制フェイルオーバーを行う、といった取り決めを行っておく。また、このようにあらかじめ定めた条件の下でフェイルオーバーを行った場合、後から「わざわざフェイルオーバー作業を行わなくてもよかったのではないか」という批判が起きないよう、関係者間で事前に認識をすりあわせておくことが重要となる。

　筆者の顧客の中には、議論を尽くした上で、このように重要かつ難しい判断を代行者（特にDRサイトを運用している社外のベンダー）に行ってもらうのは事実上困難だとの結論に至ったケースがある。

　この場合は、顧客の中で一種の割り切りを行い、「ある一定期間誰とも連絡が付かなければ、即時フェイルオーバー切替を行ってよいこととする」と取り決め、書面を交わすことで意思決定が容易になる。有事の際に情報が氾濫する中で難しいことを考えるよりも、有事発生からの経過時間とマスコミ報道の有無という、誰でも判断可能な簡単な指標を判断基準としたわけである。

　この結果、まずはコミュニケーション手段の復元を優先順位の高い目標とし、電子メールやリモートアクセスシステム、IP電話を復旧させるという意思決定を下すというのが、この顧客が至った現実解であった。

　災害発生後は、被災地はもちろん、DRサイト側でも種々の情報収集のためにどうしてもバタバタしてしまうものである。そのような状況下では、意思決定の判断基準が複雑になると機能しない恐れがある。何か起きたらすぐにフェイルオーバー宣言を行える実装にしておくことの重要性が分かるだろう。

　例えば、簡単にフェイルオーバー／フェイルバックが可能なように必要なデータ量を極力絞ったり、プライマリサイト側のサービスとDR側のサービスとが独立して同時起動できるような疎結合の実装が可能な設計にするといったことが考えられる。こうした事柄こそ、本当に災害に遭った際、ディザスタリカバリシステムが有効に機能するかどうかの分かれ目になると改めて勉強した次第だ。