何でも書き込もう

今回は「ITサービス継続性管理」について解説する。言葉だけをとらえると「可用性管理とどう違うの？」と感じるかもしれないが、その中身は根本的に異なるものであり、当然行うべきプロセスも異なる。

ITサービス継続性管理プロセスの役割

　ITサービス継続性管理の目的は、火災、台風などの風水害、地震、大規模停電、テロなどの「災害」によってITサービスが停止に追い込まれたときに、ビジネスを継続させるために顧客と合意した時間内にITサービスを復旧させ、ビジネスへの悪影響を最小限にすることである。

　最初に可用性管理との共通点、相違点について考えておこう。共通点は「ITサービスが停止することによってビジネスに与える影響を最小限におさえる」ことや「さまざまな対応や対策をビジネスを主眼において行う」ことである。一方の相違点は、それぞれのプロセスの着眼点である。可用性管理は、ITサービスを提供する構成アイテム（CI）そのものの信頼性や可用性に注目して、各CIがどの程度ITサービスを継続して提供する能力があるか、ということを向上させるプロセスである。それに対しITサービス継続性管理は、災害に代表される外部要因に注目して、その外部要因がITサービスを停止させてしまうことに対するリスク評価を行い、ITサービスの継続性を向上させるプロセスである。

　本来ITサービス継続性管理（長いので、ここから先はITSCM：IT Service Continuity Managementと略す）は、事業継続性管理（BCM：Business Continuity Management）の一環として行われるべきものである。BCMとは、事業を継続していく上で許容できる範囲でリスクを低減させることと、そのリスクが実際に発生してしまった際に迅速に復旧させるための計画を立案し、ビジネスに与える影響を最低限に抑えることを目的とした活動である。その企業のビジネスにどのようなリスクがあるのか、リスクを低減させるためにどのような方法があるのか、そのリスクが顕在化したときはどのように対策をとるべきか、といったことを、平時から計画・立案しておくのである。

　筆者は、先日ある会合で、こんなエピソードを聞いた。ある大企業の本社ビルは東京にあり、地下1階にその企業の基幹システムやさまざまなサーバを設置したマシンルームがある。とあるシステムインテグレータの営業が「御社の基幹システムのバックアップを、地震や水害の少ない○○県にある、わが社のデータセンターに置きましょう。万が一、東京に大地震が起きて、本社ビルが倒壊してしまっても安全です！」という提案をしてきたという。提案を受けた企業の取締役はその提案を一蹴した。「本社ビルが倒壊してしまったら、役員クラスも全員死んでいるだろう。データだけが残っても、ビジネスどころの騒ぎではないよ」と言った、という。

　私はこの話に違和感を持った。システムインテグレータの営業はおろか、その大会社の役員さえも、BCMについてまったく考えていない、と感じたからである。たとえ本社ビルが倒壊して、役員クラスの人間が全員死亡してしまっても、それが原因でビジネスが完全にストップしてしまったり、あるいは会社そのものを停止させてしまったりしてはならない。上場しているような大企業であればなおさらである。BCMプロセスをきちんと回しているのであれば、役員はこのような返事はしなかったであろう、例えば地震がおきて本社ビルが倒壊する、ということがリスクとして認識できていれば、そのリスクを低減させるために最初から本社機構を地震の少ない○○県に移しておくとか、本社ビルに耐震・免震対策をとっておくとかのリスク低減を行っているはずである。あるいはリスクが顕在化して本社が壊滅的な打撃を受けてしまった際には、臨時にどこを拠点にするとか、役員が死亡してしまった場合はだれがその代理をするのかなどのビジネスを止めない対策をたてているはずである。

　TSCMはそのようなBCM活動の一部である。BCMで取り決められた内容がITSCMプロセスのインプットとなり、具体的な活動が行われるようになる。

ITサービス継続性管理の活動

　ITSCMの活動は、図1の通りである。全体としては4つの段階に分かれている。


図1：ITサービス継続性管理の活動

1.開始

　最初に全員がITSCMの必要性や重要性を認識するよう組織としてのポリシーを明確にし、全員に周知するところから始まる。また、ITSCMの責任範疇や適用範囲を明確にし、メンバーの確保と役割の決定、予算の確保といった作業を行う。ITSCMは、最初の段階ではプロジェクトとして立ち上げる。そして一連の導入が完了した段階で、継続した改善を行うための日々のプロセスに変化する。

2.要件と戦略

　次に、災害など考えられるリスクを想定し、その災害が発生した場合にビジネスに与えるインパクトを明確にして評価する。どのようなリスクがあるのか、そのリスクが顕在化したらどのようなビジネス上の損失があるのか、リスクに対してどのように対応するのか、ということを考える段階である。

　ビジネスに対するインパクトは、売上げの損失、資産喪失や修理に関する損失、マーケットシェアの損失、社会的信用の損失などについて考える。リスクを評価するには前回紹介したCRAMMなどの方法を用いる。これは「資産」「脅威」「脆弱性」の3つの観点で考えると分かりやすい。例えば本社ビル内の顧客データという「資産」に対して「本社ビルの近所にある川が大雨で決壊してビルが浸水し、顧客データを失う」という脅威があり「堤防や耐水対策などの措置をとっていない」という脆弱性を持っているのであれば、それはリスクである。資産価値の高いものに対して大きな脅威があり、脆弱性が高い場合は「リスクが高い」といえる。

3.導入

　ITSCMを実施するための組織を設立したり、リスクの高さにあわせてさまざまな対策を導入したりする段階である。また、対策を実施するメンバーは全員がITに詳しい人間であるとは限らない。手順を自動化できない部分は必ずその手順を文書化して安全な場所に保管し、校正管理データベース（CMDB）内に一つのCIとして登録しておくことが望ましい（災害が発生したときにその手順が参照できないのでは何にもならない）。

4.運用管理

　導入が完了すると、ITSCMを通常業務の一環として継続して活動する必要がでてくる。防災訓練と同様、ITSCMの復旧計画は定期的にテストされなければならないし、その復旧計画が適切であるかどうか、ビジネスの変化に対応できているかどうか定期的にレビューされる必要がある。また、ビジネスの変化に伴ってITサービスそのものが変化していたり、CIが変更されたりした場合は、復旧手順も変更管理に基づいて変更する必要がある。

　ちなみにITILでは「教育」と「トレーニング」を違う意味で使っている。ここでいう教育とは、ITSCMの意義や役割を関係するすべてのメンバーに理解させ、それが重要なプロセスであるという認識を周知徹底する活動のことである。またトレーニングとは、災害時の復旧計画に備えてメンバーの活動能力を高めることである。

復旧オプションの種類

　ITサービスを提供するITインフラや建物などの設備、電気、インターネット接続などのライフラインに被害が出た場合、とりうる復旧オプションの種類には次の6通りの選択肢がある。もちろん、どの選択肢をとるか、ということは、被害を受けた対象物がビジネスに与えるインパクトの程度や、被害そのものの程度などによって決定することになる。

1.何もしない

　文字通り、何もしないこと。十分に機能する代替策がすでに存在して稼働していたり、そのビジネスそのものを災害を機に完全に停止させてしまう場合に有効な選択肢である。

2.手作業

　ITサービスが提供していた作業を、ITがまだ存在しなかった手作業の時代に戻って行うこと。すべての業務が手作業に戻れるとは限らないし、効率も極端に落ちるだろう。たとえわずかでも動き続ける必要のある部分から優先順位をつけて対応し、災害による脅威が去った後で時間をかけてITSCMに基づかない復旧を少しずつ行っていく。高次元の復旧オプションの選択に多大な費用がかかって現実的でない場合や、ほかの復旧オプションがまだ完成していない場合の措置である。

3.相互協定

　自社と同様のITサービスを持っている他社と、災害時の相互利用の協定を結ぶこと。セキュリティ面やキャパシティ面ではあまり現実的ではない。しかしバックアップ媒体の保管場所としてや、輸送手段や通信手段などの一部の利用に限っては有効である場合がある。

4.段階的復旧

　コールド・スタンバイともいう。IT復旧までに72時間程度の猶予が持てる場合に有効な手段である。一般に代替のインフラを用意しておかず、サービスを提供する外部組織のインフラを借りたり、仮設のプレハブに災害時に代替設備を借りたり購入したりして準備し、そこにバックアップ媒体からシステムやデータを戻す、という手法である。

5.中間的復旧

　ウォーム・スタンバイともいう。IT復旧までに24時間～72時間程度の猶予が持てる場合に有効な手段である。災害が発生した際に、あらかじめ用意しておいたバックアップシステムに切り替えて稼働させる方法である。バックアップシステムは自社で用意して普段は稼働させないでおくか、または代替機を提供する外部サプライヤと契約しておき、災害発生時に迅速にセットアップするような方法を用いる。

6.即時的復旧

　ホット・スタンバイともいう。IT復旧を24時間以内に行うことを目標とする手段である。一般に、稼働環境とぼとんど同じシステムを稼働環境と十分離れた別の場所に常に用意しておき、システムやデータの同期をとっておく。稼働環境が被害にあった際に即座にバックアップ環境に切り替える方法である。実現には非常にコストがかかるが、ITサービスの即時復旧がビジネスを継続する上で必要な場合はこのオプションを選択する。

ITサービス継続性管理のKPI

　ITSCMのKPI（重要業績評価指標）がうまくいっているかどうかを評価するためのKPI（重要業績評価指標）には、次のようなものが考えられる。

　　　ITSCMに含まれなかった、本来含まれるべきITサービスの数
　　　レビューによって明らかになった問題点の数
　　　テストによって明らかになった、計画通りに復旧されない対策の数
　　　顧客やユーザーに対する認知度調査
　　　顧客満足度、ユーザー満足度

　前回「100％の可用性はありえない」と書いた。同様に、100％安全なインフラは存在しない。日本ではテロの危険性は欧米に比べて少ないかもしれないが、そのぶん地震や台風などによる被害は欧米よりも多いと言えるだろう。筆者は1995年に起きた阪神・淡路大震災の被災者である。個人的な尺度と事情で恐縮だが、筆者の周りの全事業者のうち、あの震災が原因でビジネスそのものを辞めてしまった事業者が少なくとも25％は存在した。「関西に大地震は起きない」という伝説を、皆が信じていた。しかし現実はそうではなかった。あの地震から数年間は、個人用の耐震グッズが飛ぶように売れた。建物に対する耐震・免震構造に関する関心も高まった。さて、あなたの会社は災害に対してきちんと対策を講じているだろうか？