IT災害復旧計画を策定してみる

ステップ3：災害復旧計画（DRP）立案

ビジネス影響度分析とリスクシナリオの分析結果から、リスクシナリオで想定した事態が発生した場合に、復旧要件に従ったシステム構成を考え、またそれを運用するための体制や手続きを検討しDRPを立案する。以下はシステムごとの要件を満たすシステム構成を検討したものである。

■オンライン受注システム

優先度1（RPO＝ゼロ、RTO＝1時間、許容停止時間＝1時間）
遠隔地へのHAクラスター（マルチサイトクラスター）とデータの同期複製が必須要件となる。常時稼働状態のバックアップサーバーを外部のデータセンターに配置することは、コストの面で割高となるため、大阪支店のサーバールームにバックアップサーバーを配置し、データの同期にはホストシステムで稼働するレプリケーションソフトによる同期レプリケーション構成とした。災害発生時にはシステムは自動で、数分以内にバックアップサーバーへと切り替わり、オンライン受注システムが再開できる。系経路？回線？の切り替えは専任のオペレーターでなくても実施できるよう切り替え手順を簡素化している。

■グループウエア

優先度2（RPO=8時間、RTO=16時間、許容停止時間＝24時間以内）
オンライン受注システムのインフラをそのまま流用しコストをセーブするとともに、データ同期回線の帯域を圧迫しないように、データの同期は3時間ごとの非同期レプリケーション構成とした。災害発生時には数分以内にバックアップサーバーへと切り替わり、グループウエアシステムが利用できる。

■ERPシステム

優先度3（RPO=2日、RTO=24時間、許容停止時間＝3日以内）
災害時に24時間以内に2日前までのデータで業務が再開できればよいことから、外部データセンターにバックアップサーバーを設置し、通常は電源を落とした状態のコールドスタンバイ構成とした。データは即時性が求められないため、デジタルリニアテープ（DLT）による日次バックアップをトラック便で毎日搬送しデータセンター内に保管。災害発生時に、データセンターのオペレーターがマニュアルに従って、システムを起動しデータを最新のDLTからデータをリストアすることでERPシステムが利用できる。

■ファイル共有システム

優先度4（RPO=5日、RTO=24時間、許容停止時間＝特になし）
災害時に24時間以内に5日前までのデータを利用できればよいことから、ERPシステムと同じインフラを利用した外部データセンターでのコールドスタンバイ構成とした。データはDLTによる週次バックアップを毎週金曜日深夜に行い、ERP用データと同じトラック便で搬送しデータセンター内に保管。災害発生時に、データセンターのオペレーターがマニュアルに従って、システムを起動しデータを最新のDLTからデータをリストアすることで最大5日前までのデータが利用できる。

表3はこの構成案をさらにコスト面と運用面で見直しをして、より具体的な構成にした結果である。見直しのポイントは以下である。

■オンライン受注システム

DRサイトの設置・運営コストを低減するために、大阪支店のサーバールームにバックアップサーバーを配置する案を検討したが、クラウド環境を積極的に利用することで、ホットサイトの形態を保ちつつディザスターリカバリー（DR）サイトに関わるコストをさらに削減することができる。
また、インターネット経由での専任オペレーターによるセキュアな操作が可能となるため、オペレーターは場所を選ばずにインターネット経由で待機システムでの業務再開を確実に行うことが可能である。
この構成は、HAクラスタソフトとレプリケーションソフトにサイオステクノロジー社の「SteelEye LifeKeeper」と「SteelEye DataKeeper」、クラウド環境にはIBMの企業向けパブリック・クラウド・サービスである「IBM Smart Business Cloud - Enterprise」を選定して実現する。

■グループウエア

グループウエアはクラウドの「Google Apps for Business」へ切り替えることで、専用サーバーやプログラムのメンテナンスにかかるコストの大幅な削減を図るとともに、本番サイト、DRサイトの運用に関わらず常に利用可能な状態を維持できる環境とした。
また、パブリックなクラウドサービスであるGoogle Appsのセキュリティ面での脆弱（ぜいじゃく）さをカバーするため、特定のネットワーク（IPアドレス）や許可された端末（PC、スマートフォン、携帯電話）のみにアクセスを許可するアクセス制御の仕組みを提供するサイオステクノロジー社のクラウドサービス「C3（Cloud Computing Control）」を利用した。

■ERPシステムおよびファイル共有システム

バックアップソフトによって仮想テープライブラリにバックアップされたデータは、レプリケーションソフトによって常にDRサイトに退避しておく方式を採用した。これによりバックアップからのデータ復旧においては、本番サイトからのテープ搬送を定期的に行う手間とコストを省くだけでなく、DRサイトでの速やかなデータ復旧を可能としている。
もちろん、リモートからのセキュアなアクセスが可能なクラウド環境であるため、オペレーターがDRサイトに出向く必要がない。さらに、交通網の遮断によりバックアップメディアをDRサイトに搬送できないという事象も回避できる。バックアップソフトには、クエスト・ソフトウエア社の「NetVault Backup（以下NV Backup）」を使用し、NV Backupの仮想テープライブラリ（VTL）が格納されているディスクをサイオステクノロジー社の「SteelEye DataKeeper」によりDRサイトにボリュームレプリケーションする。

ここでもDRサイトには「IBM Smart Business Cloud - Enterprise」を利用した。通常時はVTLのレプリケーション先としてだけの利用であるため、サイトの形態はコールドサイトとなるが、「IBM Smart Business Cloud - Enterprise」は起動申請後最短10分で使用できるため、実質的にはウォームサイトと同等の形態となり、速やかなDRサイト構築が可能となる。

まとめ

これまでに述べたように、検討すべき項目、ステップはBCP、ITSCM、IT-DRPの全てに共通している。停止・中断の要因（リスク）と事態（シナリオ）を洗い出し、ビジネスへの影響度から優先順位付けを行い、そして停止・中断が最小となるような代替案を検討して計画書としてまとめるというステップである。これらのステップを実行する際に重要となる指標が、RPO、RTO、RLO、MTPDになる。

これらの指標を用いて最適な代替案を検討していくが、忘れてはならないもうひとつの指標はコストである。事業継続のために必要な計画は、投資可能なコストの中で実現しなければならないからである。コストと密接に関連する指標はRPOとRTOで、いずれもゼロに近づくほどコストは高くなる。「バックアップかレプリケーションか？」、「ホットサイトかコールドサイトか？」という形態をコストとの関連で選択していく必要がある。

BCPが対象とする事業・業務の範囲をITシステム関連に絞り込むことで、BCPという非常に対応範囲が広く、着手がなかなか困難である状況を打破できる。さらに想定されるリスクとシナリオを、災害とITシステムの停止・中断に絞り込むことで、ITシステムの災害復旧計画を立案することが可能となる。IT-DRPはBCMに包含されるため、正しいステップで計画することで単独で実行しても問題ない。

ビジネス影響度分析の評価指標は、可能なかぎり定量的な指標である損失金額で行うことが望ましい。そして、計画を実装する際には投資可能なコストの範囲内でRTOを最小にできる構成とすることが重要である。