ページの本文へ

Hitachi

株式会社 日立コンサルティング

ディザスタリカバリ対策、最初の一歩 〜具体的アプローチを示す

株式会社 日立コンサルティング ディレクター

2011年7月11日

いまやITシステムは企業の根幹を成すものとなった。したがって、事業継続においてもITシステムが動き続けている事が非常に重要なってくる。では、どのように止まらないITシステムを作るべきなのだろうか。

ビジネス視点からのアプローチ

  1. 業務プロセスを可視化しインパクトを洗い出す
    ITシステムのディザスタリカバリ(DR)対策を検討した場合、どのシステムに、どの程度の可用性を持たせ、どの程度の投資をするべきかがなかなか決まらず、いつまでも本格着手出来ないというケースが多いのではないだろうか。これはITシステム担当者が業務プロセスを正確に理解しておらず、業務の特性や重要性を判断出来ないというだけでなく、業務担当者もその業務が停止した場合のインパクトや影響範囲を正確に伝える事が出来ず、復旧要件やサービスレベルをなかなか定義出来ない為と考えられる。また、多くの企業でITシステム担当者が中心となり、DR対策を検討している。そのため、IT視点からのアプローチに偏ってしまい、どのテクノロジをどこに適用するかという話に終始してしまう事も一因と考えられる。したがって、ITシステムのDR対策を検討する際に、最初に行っておくべきポイントは、対象となる全ての業務プロセスの可視化とそのプロセスが停止した場合のビジネスインパクトを明確にしておく事である。
  2. 業務プロセスの優先度
    洗い出したインパクトに対し、緊急度、重要度の観点から優先順位付けを行う。例えば、大きな利益損失や顧客からの信頼低下といった顧客にも自社にも多大な影響が想定されるインパクトは優先度1。逆に影響範囲も狭く、ある程度の被害が発生しても許容出来る範囲と考えられるインパクトは優先度3といった具合だ。そして、その優先度を業務プロセスに再度当てはめ、業務の特性や代替え手段の有無等を勘案し、最終的に各々の業務プロセスを優先度別にクラス分けする。このクラス分けは、3〜5クラス程度が妥当と考えられる。後に説明するが、このクラス毎に非機能要件、適用するテクノロジが決まる。その為、あまりクラスが多いと定義する要件やテクノロジが多数になり煩雑になるだけでなく、運用形態も多岐にわたり、運用コストが高くなってしまうためだ。
  3. 非機能要件
    クラス分けが完了したら、クラス毎に可用性やサービスレベルなどの非機能要件を定義する。最上位のクラスであれば、RTO(目標復旧時間)は数秒〜数十秒、RPO(目標復旧時点)は障害直前といった厳しい要件が定義されるであろうし、最下位のクラスであれば、復旧までに数日を有すことも許容されるかもしれない。ここでのポイントは、定義された非機能要件がクラスに属している全ての業務プロセスに適切か否かである。もし、適切でない要件があった場合、要件自体が間違っているか、その業務プロセスの属するクラスが正しくないという事になる。

IT視点からのアプローチ

  1. ITシステムの可視化
    さて、ここからは業務から少し離れ、IT側からのアプローチとなる。まずは、現行システムの棚卸が必要になる。対象となっている業務プロセス毎に使用しているアプリケーションとITリソースを整理、可視化する。併せて、現行システムの特性や課題があれば、ここで全て洗い出し、今後適用するテクノロジやソリューションへのインプットとする。また、この時点でそのシステムに掛かっている運用保守コストもある程度、算出しておきたい。DR対策を阻害する大きな要因として、まだ起こっていない事象に対して、どの程度の投資をするべきか判断出来ないという点がある。クラウドコンピューティングなどを利用すればDR対策も行え、運用保守コストも下がる可能性がある。その指標に必要となるからである。
  2. アーキテクチャデザイン
    ここでは具体的な実装方式の検討を行う。理想はクラス毎に実装方式や実現策をひとつにする事だが、既存システムのアーキテクチャや利用しているテクノロジの違いによりひとつにまとめるのは難しいかと思う。クラスによって若干異なるが、システム特性によってある程度グルーピング化し、グループ毎に方式を決定するのが現実的だろう。または、逆に適用するソリューションを先に決めてしまい(例えばSaaS)、そのソリューションに対応出来るシステムを決定するという方法も考えられる。

    ここで重要なポイントは、クラス毎に定義された非機能要件を必ず充たしている方式をデザインする事である。特に実装や運用保守に掛かるコストがネックとなり、要件レベルを下げる事は避けたい。また、実装方式によっては待機リソースを有効活用する方法も考えたい。待機サイトを読み取り専用にするなど、利用テクノロジにより、いくつか方法はあるはずだ。

DR対策する事のメリット

BCPの1ファクターとして重要な役割を果たすだけでなく、上記のプロセスを経る事で無駄なITリソースや過剰投資しているシステムなどが判明し、システムの全体最適や標準化を促進する事も可能となる。また、今回は触れていないが利用者側の対策(DaaSなど)を進める事で分散オフィス環境などのBCP対策をシステム側から推進する事も可能となる。このように単体のシステムを個々にDR対策するのではなく、全体または広範囲の業務を網羅し、対象システムを広げる事で享受できるメリットは少なくない。それ相応の対策には、それなりの投資も時間も必要となるが、ぜひビジネス視点を取り入れたアプローチで適切な対策を施してほしい。

出典:アイティメディア株式会社 TechTargetジャパン (新規ウィンドウを表示)

本コラム執筆コンサルタント本コラムへの感想などはこちらから

株式会社 日立コンサルティング シニアコンサルタント

企業にとって多くの想定外が発生した東日本大震災。事前に策定していたBCP(事業継続計画)の実行にも混乱が見られました。そこから学ぶことができるBCPの課題と今後の対策について、コラムでご紹介します

※記載内容(所属部署・役職を含む)は制作当時のものです。