一体どこまでが最悪の事態？
事業継続(BC)の重要なポイントとして最悪の事態を前提に物事を考えるというのがあります。でもよく考えると一体どこまでが最悪の事態なのでしょうか？
前回、神戸製鋼所のコンピュータシステム災害対策広報について触れましたが、この広報文の最後に注意すべき但し書きがありました。
「2箇所のデータセンター（灘浜と加古川）が同時に、震度7クラスの地震を受ける確率が極めて低いことから、本対策は有効であると言えます。」
神戸製鋼所では、主要なデータセンタが3つあり、それらはお互いに十分離れているので、地震などが発生しても同時被災する確率は十分低いと判断されていることです。
加古川（兵庫県）--- 40km --- 灘浜（神戸市）--- 680km --- 真岡（栃木県）
でも最悪の事態を想定するなら、いくら離れていようが3つとも使えなくなることを想定すべきではという疑問が出てきます。
しかし無限に最悪の事態を想定していくと、地球が吹っ飛ぶことまで考えなくてはなりません。これではBCを考えるどころの話ではありません。
やはりどこかで線引きをするのが現実的のようです。
日本は地震が多い国なので、どうしても距離に関心が行きます。よく聞く質問に「何キロ離れていればいいんでしょうか？」「何か基準は無いんでしょうか？」というのがあります。
金融庁が出されているFISC安全対策基準には、以前、バックアップの隔地保管について60kmという記述がありましたが、2004年3月5日の改定で削除され表現が変更されています。
60kmも離れていると、バックアップサイトに行くのには遠すぎるという意見もあったと聞いています。
また災害時に交通規制がどう引かれるかも要注意ポイントです。
よく言われているのが、あるエリア内から外に出てしまうと、消防や救急などの緊急車両以外当分中に入れてもらえなくなるということです。
また空路を使わなければならない場合、天候やテロのために空港が閉鎖されないかという面を気にしなくてはなりません。出来れば陸路で何とか行ける範囲に収めたいところです。
今の時代インタネットで繋がっていれば、わざわざバックアップサイトまで行かなくても良いのでは？という発想も出てきます。
でも現実には復旧作業中にテープを入れ替えたり、CD-ROMを入れたり、リセットボタンを押したり、電源を入れ直したりと、何かと操作が必要になることも多いようです。
この辺りは日頃の訓練で諸問題を潰しておく、また場合によってはバックアップサイトにいる人に作業を頼んでおくといったアレンジも必要でしょう。いやいや当日電話で頼めばいいよ、なんて思っていると、電話が繋がらなくて往生するかもしれません。
アメリカの方はどうなっているかというと、Disaster Recovery Journalという雑誌がWeb上で行ったアンケートで以下のような結果が出ています。
June 24 - July 7, 2002
How many miles is your alternate data center from your main data center?
あなたの代替データセンタは元のセンタから何マイル離れていますか？
0- 50 : 45.12% （0～80km）
250+ : 31.71% （400km以上）
100-250 : 13.41% （160～400km）
50-100 : 9.76% （80～160km）
アメリカは国土が広いので、日本と単純な比較をすることは出来ませんが、80km以下の場合も多いようです。またアメリカにはSunGardのような代替データセンタをアウトソーシングで提供するベンダが存在し、一般的に使われているので、必ずしも自社の施設間の距離ではなく、そのベンダのセンタまでの距離が影響していることが十分考えられます。
もっともデータセンタが集中するニューヨークでは、9.11同時多発テロ事件の際に、対岸のニュージャージーで復旧が行われたので、かなり近い距離ということになります。
ところが、2003年の東海岸地域一帯での大停電の際は、被害が広域に渡ったので、やはりセンタ間の距離をもっと離すような考えもその後出てきているという話も聞きます。
BCは災害の要因にはとらわれないで、最悪の事態を想定し、対策を立てるのですが、日本の事情を考慮すると、地震による同時被災を避けるというのは、現時点では現実的な選択ではないかと思われます。
距離の話に戻りますが、同じ断層の近くに無いか、同じ電力網の中に無いか、ネットワークは複数あるかなど、個別の事情を考慮して、最終的にはその企業にとって、許容できそうなリスクの範囲で決めることになるでしょう。
代替サイトは出来るだけ離れていた方が良いが、人が何とか行ける程度にしておくのも現実的なようです。
この最悪の事態の想定は、事業継続計画(BCP)を検討する初めに、一般的にはビジネス影響分析(BIA)を実施する前に、十分調べて合意しておくことが重要です。これが曖昧だと後の議論で、「そこまでは考えていなかった」「そんなの知らなかった」などということが起こって、検討が中断したり、遡ってやり直しということになりかねません。
じゃあ、「こんな風に最悪の事態の想定を限定するのはインチキくさい？」と思われるかもしれませんが、その企業にとってのリスク許容度とのトレードオフなので、気になるときは、BCPの中に残余リスクとして、「2つのサイトが同時被災した場合は、更に別の場所での事業継続を検討する必要ある」などと書いておいて、将来BCPを見直していく過程で、徐々に最悪の事態の範囲を広げていくのが現実的ではないでしょうか。
最終更新時間 20:55 | コメント (3) | トラックバック
事業継続(BC)のための災害対策を広報する
先日、神戸製鋼所がコンピュータシステムでは事業継続(BC)を最重要課題と位置づけて、その災害対策について広報されていました。
広報文は以下をご覧下さい。
ホストコンピューターの災害対策の強化について
鉄鋼業界初の"遠隔地同士の相互リアルタイム・バックアップ体制"を整備
災害対策は3つの骨子からなっています。
(1) 免震床の導入
これはいわゆる機器の防災の範疇です。
やはりまず元のサイトがしっかりしていないといけないので、何らかの対策を採られているところも多いかと思います。
(2) 同一データセンター内でのディスクの相互バックアップ
これはどちらかというと物理的破損も含めた障害によるデータ破壊による被害を最小限に留めようというものです。
データのバックアップはテープにとっておくのが一般的ですが、ディスクを使うことにより、すばやく別系統のシステムに切り替えることが可能になります。
(3) 遠隔地同士（灘浜データセンター／加古川データセンター）の相互バックアップ
これはまさにBC対応です。
BCでは、最悪の事態を想定するので、元サイトで免震床を導入してようが、センタ内で相互バックアップをとっていようが、外とのネットワークが切れる、停電のため自家発電に切り替えたが燃料が尽きてしまいまた停電する、センタの近くでテロ事件が発生して誰も近づけなくなる、などの理由で結局元サイトが使用不能になることは起こりうります。
そこで代替サイトでのシステムに切り替える何らかの方策が必要になってきます。
神戸製鋼所では、こういう事態が起こることも想定して、遠隔地同士での相互バックアップに踏み切られたようです。
システムの技術的な話はさておき、BCに対する取り組みをアピールすることは今後ますます盛んになると思われます。
BCに対する投資は、保険であり無駄だとマイナスの発想をするのではなく、危機に強い企業になり、社会的責任を果たし、貢献していくというプラスの発想で捉え、広報などを活用していくことが重要になってくるでしょう。
