システム冗長化だけがDR対策ではない

企業のディザスタリカバリ対策は機能したか？

東日本を襲った2011年3月の大震災。企業のディザスタリカバリ（災害復旧）対策は、十分に機能したのか。企業のディザスタリカバリ対策支援を行っているプライスウォーターハウスクーパースの担当者に話を聞いた。

公開 2011年05月10日 09時01分

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

著者

翁長潤

[TechTargetジャパン]

印刷する

　東日本大震災では地震や津波による直接の被害に加えて、計画停電など多くの企業の事業活動に影響を与えた。ITシステムにおけるディザスタリカバリ（DR）対策の見直しを検討する企業も多いだろう。DR対策の課題とその見直しのポイントについて、実際にDR計画の策定を支援しているプライスウォーターハウスクーパースの担当者2人に話を聞いた。

企業のDR対策は機能したのか？

プライスウォーターハウスクーパース　テクノロジーソリューション　マネージャー　一原盛悟氏。事業継続案件や内部統制、情報セキュリティリスクに関するアドバイザリー業務を担当。また、行政機関のパンデミック対策、民間企業における首都直下型地震時の本社機能のBCP策定などを支援

――今回の東日本大震災では、企業のDR対策は十分に機能したと思いますか。また、機能していなかった場合は、その原因として何が考えられますか。

一原氏：企業が事前に策定していたDR対策が機能したかという点では、基本的には「NO」だと考えています。DR対策でITシステムが稼働しても、企業の事業が継続できていなければ意味はありません。業務部門のBCP（事業継続計画）とIT部門のDR対策の両方が機能する必要があります。BCP／DRの取り組み（図1）の中では、それぞれの事前対応計画の1つに「定期的なテスト訓練」を挙げています。今回はそうしたテスト訓練が十分でなかったために「バックアップシステムへの切り替えができない」「サーバ代替機が搬入できない」「データのリストアができない」という企業があったと考えられます。

図1：業務部門（BCP）、情報システム部門（DR）の取り組み

プライスウォーターハウスクーパース　テクノロジーソリューション　マネージャー　藤原崇氏。データセンター選定、ネットワークインフラの見直し、基幹系アプリケーションの仮想化への移行、移設などを担当。通信事業者向けのBCP策定支援、データセンターおよびバックアップセンターの選定なども支援

藤原氏：今回のような地震や津波、原子力発電所事故などの災害レベルは、これまで私が携わってきたBCPでは「一般的な企業が対処する必要がない」もしくは「発生頻度が著しく低い事象であり、対策を打つ必要がない」という想定外のリスクとして考えられていました。そのため、多くの企業がそのリスク自体を想定しておらず、具体的な対応策が検討されていなかったことが顕在化したといえるでしょう。

――なぜ、テスト訓練は難しいのでしょうか。

一原氏：例えば、DR対策テストの1つに「本番系の基幹系システムを停止し、再起動・動作確認をする」という訓練があります。しかし、本番システムを停止することで事業活動が妨げられたり、再起動できなかった場合のリスクなどが出てきます。実際にこのテストを実施していた企業はかなり少ないでしょう。とはいえ、今回の影響を受けて、システムダウンを想定した訓練の必要性を認識した企業も多いと思います。

藤原氏：ホットスタンバイ用の待機系システムを保有していても、実際にシステムを切り替えた経験がある企業は限られています。テストのためにシステムを切り替えることは、現実的に難しい問題といえるでしょう。

今後取り組むべきDR対策とは

――今後企業が実施すべきDR対策としては何が考えられますか？

一原氏：既にDR対策を実施してきた企業でも、その前提条件をあらためて見直す必要があります。現在、首都圏に拠点がある多くの企業では、内閣府の中央防災会議の「首都直下地震対策」で提示されている「東京湾北部でマグニチュード7.3の地震が発生した場合」の被害想定を前提としています。しかし、本当にその前提条件が妥当であるかどうかをあらためて検討するべきです。また、東京電力が3月に実施した計画停電も企業にとって全くの想定外の出来事であり、これまでの前提条件が覆されたといえます。そうした前提条件を見直した上で、あらためてその対策を考える必要があるでしょう。

藤原氏：前提条件における評価基準の見直しも必要です。例えば、津波対策の評価基準としては、中央防災会議の「首都直下地震対策専門調査会」の基準を参考としている場合が多いです。その場合の想定では「東京湾内は50センチ、湾外は2メートルの津波」となっています。そうした評価基準が妥当かどうかを検討したり、想定を超えた事態が発生した場合にどう対処するかという点まで含めた見直しも必要になるでしょう。

――他にも考慮すべき項目はありますか。

一原氏：これまでのデータセンター選定におけるRFP（提案依頼書）では、データセンターの立地や地盤、耐震性などが評価されていましたが、それ以外にも「電源の確保」についてもより踏み込んだ評価が必要になります。これまでもデータセンター事業者では2系統の発電所から電力供給していたり、自家発電設備があることをアピールしてきました。今後はさらに「自家発電装置の容量はどれくらいなのか」「UPSはどれくらいの時間持つか」など、より厳密に確認する必要があると思います。

藤原氏：また、「自家発電における燃料供給体制や優先契約内容の確認、稼働テスト実施の有無」など、パンフレットやカタログなどには記載されていない情報を確認することも重要です。

システムの冗長化だけがDR対策ではない

――広域災害が起こる場合を考慮して、自社でのシステム保有からデータセンターの利用へ移行したり、「セカンダリサイト構築によるシステムの二重化」を行ったりとITシステム構成を見直す企業が増えると思いますが、その点はいかがでしょうか？

一原氏：DR対策として「セカンダリサイト構築によるシステム二重化」ありきで検討を進めるのが最適な策であるかは疑問です。そのメリットは、緊急事態が発生した場合でも稼働できるという「可用性の向上」が考えられます。しかし、複数拠点になることでシステムの構築費用や運用コストの増大なども考えられます。また、管理ルールの策定やトレーニングといった副次的な工数も掛かってきます。これらの点を踏まえた上で、システム二重化を実施するかどうかを判断する必要があります。

藤原氏：ホットスタンバイの待機系システムを保有している企業は金融業界に多く、製造業などほとんど導入されていない業種もあります。一般的なDR対策として複数拠点におけるシステム保有は難しく、「DRの強化＝システムの分散配置」ではありません。実際にシステムを複数拠点に保有している企業ではその機能を分割していることもあり、ある拠点が被災して業務が停止した際に企業全体の事業が継続できないケースもあります。短期的には、DR対策にも有用な仮想化技術を活用して単一拠点にシステムを統合してその基盤を整えた上で、中長期的な計画としてバックアップサイトの構築に進むというアプローチが現実的だといえます。

　また今回、多くのデータセンター事業者は直接的な被害は受けていません。今後はクラウドコンピューティングへの移行の流れもあり、データやシステムなどの企業資産を自社で保有することを見直す企業も増えてくると思います。オンプレミスまたはデータセンターのどちらを選択するかについて、コストやリスク対策などのバランスを考慮した上で判断されることになるでしょう。

アクティブ・アクティブの災害対策サイトを構築した安川電機の事例

パブリッククラウドは災害対策で役に立つのか？　AWSとGIOも検証

BCPと合わせた見直しを

――あらためてDR対策を見直す上でのポイントを教えてください。

一原氏：「DR対策における前提条件やテスト内容の見直しを必ず実施する」ことです。また、テスト訓練のシナリオには、テストを受ける人が想定しないようなシナリオも盛り込んでいく必要があります。緊急時にシナリオの通りに動くことは難しいので、マニュアルに沿って臨機応変に動けることも重要です。机上だけではない、生きた訓練を実施することが大事です。

藤原氏：内閣府や経済産業省、金融情報システムセンター（FISC）の安全対策基準などを参照してきた「評価基準や想定リスクをあらためて見直す」ことです。自社で発生し得るリスクを具体的にイメージして、そのリスクをどうすればヘッジできるかを検証する必要があります。

　また、情報システム部門のDRと併せて、業務部門でもBCPについてあらためて見直す必要があると思います。多くの企業では「Y2K（2000年）問題」が収束した2000年初頭ごろからBCPの策定を進めてきましたが、当時策定されたBCPはある意味、今では前時代的になっている可能性が高いと考えられます。現在は、仮想化やクラウドなどの技術的な進展もあるので、その点を考慮した上で現状に即した対策を図る必要があると思います。

印刷する