いま見直したい、事業継続10のチェックポイント特別企画 貴社の事業基盤は“万全”ですか?(1/2 ページ)

万一の際にも、確実に事業を継続するためには、日ごろ、どんな備えが必要なのか。自社の事業継続性の現状を知るための、10のチェックポイントを紹介する。

» 2011年04月14日 12時00分 公開
[高城 涼,@IT]

企業存続の鍵を握る、事業継続の重要性

 東日本大震災、そしてみずほ銀行やゆうちょ銀行のATMシステムトラブルは、「事業継続」の難しさと重大性を認識させるものとなった。どんな企業にも取引先があり、最終消費者がいる。1つの会社の操業停止は影響の大小はあれ、関係者に迷惑を掛けるものだ。

 その一方で、何らかの突発事象があっても、事前の準備によって、最低限の活動を継続したりできる限り早期の復旧したりできれば、迷惑の度合いも小さく、信頼を失わずに済む。

 今日、企業活動のかなりの部分をITが支えていることを考えると、ITについても十分な準備が必要だ。事業継続や復旧をITが支援することはあっても足を引っ張ることがあってはならない。以下にIT事業継続に関する簡単なチェックリストを用意した。備えあれば憂いなし??災害対策や事業継続計画が未整備というIT部門の方々は、ぜひきっかけにしてほしい。

ポイントは「どんなときに、何を、どうするか」のメドを立てておくこと

事業継続チェックポイント その1

前提となる緊急事態と被害を想定しているか?


 災害対策や緊急対応計画は有事を想定して作られる。建築物の耐震性設計を行う際には想定値として上限が必要だろうが、有事への備えという意味では最悪の事態を考えるべきだろう。例えば、震度7の地震にも耐えられるデータセンターの災害対策を検討するとき、それを超える地震があったらどうするかを“考える”ためには過激な想定が必要ということだ(結論は「廃棄」かもしれない)。

 災害対策を考えるとき、根本原因ごとに見ていくと地震・台風・落雷・火災・土石流・洪水・集中豪雨・戦争・隕石・人工衛星の落下……というように無限に心配事が増えていく。これを整理するには工学でいう故障モードを援用して「ハードウェアの損傷(外部衝撃、延焼、水没、過電流)」「データセンターの損傷」「プロバイダ側の障害」「停電(予定外、予定あり)」「オフィスに入れない」「担当者が出社できない、連絡が取れない」……といったようなレベルで考えていくといいかもしれない。

 事業継続計画(BCP)はいきなり完璧なものを作る必要はない。むしろ、常に検討を繰り返し、いろいろな“想定”を付け加えていくべきものだろう。総務省や中小企業庁、自治体などで各種のガイドラインを出しているので、それを参考に自分で考えていくことが重要だ。

事業継続チェックポイント その2

重要な事業・IT資源を特定できているか?


 災害時・緊急時に行うべきことはたくさんあるはずだが、実際にできることは限られる。情報システムの継続運用や復旧の計画立案には優先順位付けが必須だ。

 一般的な事業継続計画では、ビジネスインパクト分析を行って重要業務を識別し、それを支えている経営資源(情報システムを含む)を特定するという手順を踏むことになっている。これは経営判断として行われるべきものだ。

 重要業務・重要ITのランク付けでは代替手段も併せて検討する。例えば、生産管理は人力でも行えるが、電子メールや受注システムが機能を停止すると業務も止まってしまうというような場合、後者の方が優先度は高いと判断できる。

 問題になりそうなのは、そもそも社内IT資産のすべてを総合的に把握できていない場合だ。現場部門が勝手に導入したサーバがあって、それが意外に重要な仕事をしているかもしれない。これらの調査・把握も必要だ。

事業継続チェックポイント その3

初動の手順を定めているか?


 緊急事態の発生直後は最も混乱する時期だ。そのときの対応を定めたものがコンティンジェンシープランである。全社レベルの計画としては、避難や関係機関への連絡、救命活動などの手順が定められているはずだ。この中で重要資産の運び出しについて規定されているかもしれない。情報システム部門としても、緊急時持ち出しリストを作り、担当者を決めておく。

 システム管理者が緊急対応すべきものとして停電がある。停電が想定される、あるいは想定外の停電が起こったときに二次電源への切り替えを想定しているなら、その手順を定めることになる。UPS(無停電電源装置)を導入している場合は、サーバを停止するという作業が発生する。UPSは瞬間的な停電からシステムを保護すると同時に、システムを安全にシャットダウンする時間を与えてくれる装置である。シャットダウンやブレーカーを落とすなどの手順についても定めておくと良いだろう。

 緊急時には担当者が不在だったり、連絡が取れないことが考えられる。あるいは夜間や休日の災害発生もあり得る。これらの場合の手順についても考えておくべきだ。なお、あくまでも人命優先なので、緊急度によって避難や待機が優先されるのはいうまでもない。

事業継続チェックポイント その4

サーバルームが被災した場合の手順を決めているか?


 初動に続く、BCPでいう初期フェイズでは被害状況を見極め、復旧や再開の見込みの判定をすることになる。施設や設備への影響を評価するためには、事前に必要な情報を整備しておかなければならない。

 災害対策として事前に代替施設が用意しているのならば、システム被災時にそちらを使うという決定が行われることが考えられる。ホットスタンバイのバックアップセンターを準備していて、障害発生と同時に自動的にフェイルオーバーする仕組みになっていれば、システム担当者の作業はモニタリングぐらいかもしれないが、そうでないならば切り替え作業が必要となる。

 いわゆるコールドスタンバイの場合は、代替施設の現地に行ってシステムを起動し、必要に応じてプログラムをインストールし、本番サイトのバックアップデータを移行して、テストなどを行い、ネットワークを切り替えて稼働するという作業が待っている。通常、バックアップセンターは正常系センターよりも規模が小さいので、事前に定めた重要システムだけを稼働させることになる。

事業継続チェックポイント その5

復旧手順は定められているか?


 事態が落ち着いてきたら、サーバルームの復旧作業を行うことになる。ハードウェアの筐体が強い衝撃を受けた、水没した、煙や粉塵にさらされたことが疑われる場合、むやみに電源を投入すると取り返しの付かない状態になることが考えられる。データを保護したいのであれば、専門家と相談してマシンの再起動よりもデータ復旧を優先することも検討するべきだろう。特にストレージ装置には注意したい。

 ポイントその2で検討したビジネス上のシステム優先度はシステム復旧を考える上で重要な情報だが、それだけで単純に復旧計画が立案できるわけではない。メールサーバは復旧したがネットワークにつながっていないというのでは役に立たない。一般にインフラ系の機器やシステムから回復させていくことになるだろう。

 ハードウェアが修理不能ならば新規調達が必要になるが、大規模災害後だとなかなか購入できないかもしれない。その場合には重要度の低いシステムを停止して、それが動いていたマシンに重要システムを移行することを検討する。仮想化技術でインフラが整備されていれば、移行作業自体は簡単に行えるかもしれない。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ