見直し迫られる企業の事業継続【第3回】

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

対策が求められるITシステムのディザスタリカバリ（DR）対策。どのような範囲や想定で計画すればいいのか。DR対策を行うための具体的なアプローチを紹介する。

公開 2011年07月11日 09時00分

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

[日立コンサルティング]

印刷する

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

1.業務プロセスを可視化しインパクトを洗い出す

　ITシステムのディザスタリカバリ（DR）対策を検討する場合、どのシステムに、どの程度の可用性を持たせ、どの程度の投資をすべきかを考える必要がある。しかし、その判断がなかなかできず、いつまでも本格的に着手できないというケースが多いのではないだろうか。これはITシステム担当者が業務プロセスを正確に理解しておらず、業務の特性や重要性を判断できないというだけでなく、業務担当者もその業務が停止した場合のインパクトや影響範囲を正確に伝えることができず、復旧要件やサービスレベルを定義できないからだ。

これまでの連載

　また、多くの企業ではITシステム担当者が中心となり、DR対策を検討している。そのためIT視点からのアプローチに偏ってしまい、どのテクノロジーをどこに適用するかという話に終始してしまうこともDR対策が動き出さない一因だ。ITシステムのDR対策を検討する際、最初に行っておくべきポイントは対象となる全ての業務プロセスの可視化と、そのプロセスが停止した場合のビジネスインパクトを明確にすることである。

「業務プロセスインパクトマップ」のイメージ《クリックで拡大》

2. 業務プロセスの優先度

　洗い出したインパクトに対し、緊急度や重要度の観点から優先順位付けを行う。例えば大きな利益損失や顧客からの信頼低下といった、顧客にも自社にも多大な影響が想定されるインパクトは優先度1。逆に影響範囲も狭く、ある程度の被害が発生しても許容できる範囲と考えられるインパクトは優先度3といった具合だ。

　次にその優先度を業務プロセスに再度当てはめ、業務の特性や代替手段の有無などを勘案し、業務プロセスを優先度別にクラス分けする。このクラスごとに非機能要件や適用するテクノロジーが決まる。クラスが多いと定義する要件やテクノロジーが多数になり煩雑なだけでなく、運用形態も多岐にわたり、運用コストが高くなってしまう。クラス分けは3～5クラスが妥当だろう。

「業務プロセス優先度マップ」のイメージ《クリックで拡大》

3.非機能要件

　クラス分けが完了したら、クラスごとに可用性やサービスレベルなどの非機能要件を定義する。最上位のクラスであれば、RTO（目標復旧時間）は数秒～数十秒、RPO（目標復旧時点）は障害直前といった厳しい要件が定義される。最下位のクラスであれば、復旧までに数日かかることも許容されるだろう。ここでのポイントは、定義された非機能要件がクラスに属している全ての業務プロセスに適切か否かである。もし、適切でない要件があった場合、要件自体が間違っているか、その業務プロセスの属するクラスが正しくないということになる。

IT視点からのアプローチ

1.ITシステムの可視化

　次に業務から少し離れ、IT側からDRのアプローチを説明する。まずは現行システムの棚卸しが必要になる。対象となっている業務プロセスごとに使用しているアプリケーションとITリソースを整理、可視化する。併せて現行システムの特性や課題を全て洗い出し、今後適用するテクノロジーやソリューションへのインプットに活用する。また、この時点でそのシステムに掛かっている運用保守コストも算出しておきたい。

クラウド、データセンター関連の記事

　DR対策を阻害する大きな要因として、まだ起きていない事象に対して、どの程度の投資をするべきか判断できないという点がある。DR対策にも活用でき、運用保守コストも下げられるクラウドコンピューティングは、この不確定な要素に対する投資としてリスクが少ないといえるだろう。

システム可視化のイメージ《クリックで拡大》

2.アーキテクチャデザイン

　次に検討するのは具体的な実装方式だ。理想はクラスごとに実装方式や実現策を1つに統一することだが、既存システムのアーキテクチャや、利用するテクノロジーの違いで統一は難しい場合がある。システム特性によってある程度グルーピングし、グループごとに方式を決定するのが現実的だろう。または、逆に適用するソリューションを先に決めてしまい（例えばSaaS）、そのソリューションに対応できるシステムを決定するという方法も考えられる。

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

DR対策のメリット

　DR対策の準備は、BCPの1つの要素として重要な役割を果たすだけでなく、上記のプロセスを経ることで無駄なITリソースや過剰投資しているシステムなどが判明する。また、システムの全体最適や標準化の促進も可能となる。さらに今回は触れていないが利用者側の対策（仮想デスクトップなど）を進めることで、システム側から分散オフィス環境構築などのBCP対策を推進できる。システムごとにDR対策をするのではなく、全体または広範囲の業務を網羅することで、大きなメリットを得られる。それ相応の対策には、それなりの投資も時間も必要となるが、ぜひビジネス視点を取り入れたアプローチで適切な対策を取ってほしい。