ITIL サービスデザイン − ITサービス継続性管理その１

Vol.013-(1) - 2009年06月01日

新型インフルエンザの対応同様、 ITサービス継続性管理は影響がどの程度出るのかを想定した上で様々のケースを想定して策定しなければなりません。つまり、経営者層の理解なくしては前へ進めないものです。今回のコラムではなぜそれほど重要なのかをわかりやすく説明してくれています。
by BMC編注

今回で本コラムも第13回目を迎えます。今回の内容は、サービスデザインにおける5つ目のプロセスである「ITサービス継続性管理」のお話です。

ITサービス継続性管理（IT Service Continuiry Management。以下 ITSCMと略す）は、ITIL v2 のサービスデリバリの中にもありました。その目的や内容はほとんど変わっていません。ITSCM の目的は、ITインフラストラクチャやそれが提供するITサービスの計画外の停止を、業務から要求され、合意した期間内に確実に再開させることによって、事業継続性管理プロセス全体を支援することです。

事業活動を止めてしまうイベントには様々なものが考えられます。火災、台風、地震、津波などの自然災害、テロ、破壊活動、盗難などの人災、プログラムの不具合や過負荷によるサーバの停止、停電、地盤沈下による建物の倒壊など、本当に多岐に渡ります。書籍「サービスデザイン」には、「PCの上にコーヒーがこぼれる」なんてお茶目なものまで書かれています。これらのリスクからITサービスを守り、万が一リスクが顕在化したときに備えてリスク管理を事前に行っておくことで、事業への影響を最小限に食い止めることが、ITSCMの主な活動であるわけです。

事業に負の影響を与えるイベントは、発生したときの重大性や事業に与えるインパクトによって分類できます。重大さの低い（インパクトが弱い）イベントは「インシデント」として扱い、インシデント管理プロセスで管理します。ITSCM は、発生したときの重大性が高く、事業に深刻な影響を与えるようなイベントに関して扱います。また、そのようなイベントのことを「災害」といいます。特に日本は台風や地震の多い国ですから、それらのイベントを災害と定義すればわかりやすいでしょう。しかし災害は、単にITサービスを止めてしまうものだけを指す、と思ってはいけません。深刻な情報漏えいや法律違反の露呈など、その企業の評判を落とすようなイベントも災害の一種です。ただし、ITSCM では事業の方向性、多様化、再編、主要な競合企業の失敗といった変化から生じる長期的なリスクを扱うことはありません。

ITSCMは、ITサービスが合意された範囲内で使い続けられることを保証する「可用性管理」と似ています。業務に負の影響を与える要素を分析して優先度を定め、その優先度に基づいて対策をたてる、という考え方は非常によく似ています。しかし可用性管理が日常の可用性を低くするイベント、例えば故障や過負荷などに注目しているのに対し、ITSCMは主に災害や災害と同じレベルの重大なイベントに注目している、という点が大きく異なります。

ITIL v2 の頃から言われ続けていることですが、ITSCM は事業継続性管理（BCM：Business Continuity Management）の一部です。BCMは、災害や事故などの不測の事態が発生しても事業を継続させることを保証するための活動です。ITSCM は、その BCM の中の ITサービスに関する部分を担当している、と考えればよいでしょう。とはいうものの、事業の大部分を ITサービスに頼っている昨今では、ITSCM は BCM の中核をなしていると考えても問題ないと思います。

日常の可用性を高めることの重要性は比較的わかりやすく、またそのためにコストをかけることも現場レベルやマネージャレベル、顧客レベルで承認がおりやすいものです。しかし ITSCM の場合は、いつ起こるかわからない（あるいはどの程度の被害を被るか想像しにくい）災害や事故に対する対策ですから、一種の保険のようなものだと考えられます。また、そのための対策は、可用性を高めるための対策とは違ったアプローチが必要であり、単純に可用性を高める手段に比べるとコストも高くつくように見えます。そのため、ITSCM の導入の成功には、上級マネジメント層や経営者層の深い理解と組織全体の支持が必要不可欠となります。
上級マネジメント層や経営者層の深い理解を得るためには、BCM や ITSCM がいかに重要であるか、災害や事故が現実のものになったらどれほどのインパクトが事業に対して与えられるか、ということを根拠をもって示さなければなりません。同様に組織全体の支持を取り付けるためには地道な教育・認知活動や日々のトレーニングを継続的に行っていかなければなりません。言い換えると、ITSCM は相当の計画性をもって実行しなければならない、というわけです。またその活動は継続的で、かつ定期的でなければなりません。

ITSCM の活動は、大きく４つの段階に分けられます。その４つの段階とは、次の通りです（図１）。

図１：ITIL v3 におけるサービス継続性管理のライフサイクル ITIL v3におけるサービス継続性管理のライフサイクル

１．開始
２．要件と戦略
３．導入
４．継続的な運用

この分類は ITIL v2 からあまり変わっていません。参考までに、ITIL v2 の書籍「サービスデリバリ（通称『赤本』）」に掲載されていたプロセス図をご紹介しておきます（図２）。

図２：ITIL v2　の頃の ITサービス継続性管理のプロセス図 IITIL v2　の頃の ITサービス継続性管理のプロセス図

ITIL v3 で示される図（図１）では、２つの大きな進化が見られます。ひとつは「継続的な運用」から「開始」に矢印が伸びて、これが継続的なライフサイクルとして書かれているという点です。もうひとつは、ITSCM と BCM との関係が簡単に図示された、という点です。ITSCM は常に BCM と連携を取りながら、かつ計画された保護策が最新で有効なものであることを保証するための継続的、かつ循環的な活動であるということを明らかにしているわけです。

では、それぞれの段階を簡単に説明しましょう。

１．開始　では、ITSCM 全体の方針を設定し、その適用範囲と組織内の全スタッフの責任を明らかにします。経営者層を総責任者としたプロジェクトを発足させるべきです。そのプロジェクトは複雑になる可能性があるので、PRICE2(R) や PMBOK(R) といった標準的なプロジェクトマネジメント体系を導入することが強く望まれます。

２．要件と戦略　では、ITSCM に必要な要件を定義し、戦略を整えます。

要件を定義するために用いられる代表的な分析手法のひとつに、ビジネス・インパクト分析（BIA：Business Impact Analysis）があります。BIA の目的は、サービスが停止してしまうことによる事業へのインパクトを定量化することです。事業へのインパクトは、ITインフラストラクチャの損失、データなど情報の損失、人的被害といった「ハード面」の部分と、機会損失、信用の失墜、競争上の優位性の損失、モラルや安全性の損失などといった「ソフト面」の部分に分けられます。

BIA では、ITサービスが停止してしまうことによってどれほどの損害が発生するのかを定量化すると共に、それを防ぐための予防的な対策と、リスクが顕在化した時の事後的な復旧対策を共に考えます。図３は、書籍「サービスデザイン」で紹介されている、リスク軽減と復旧に関するグラフです。これは、災害に対するインパクトが高く、できるだけ早急に復旧すべき事業に関しては「予防的」措置を重視し、インパクトが低く、ある程度の時間をかけて復旧してもよい事業に関しては「継続的」措置、つまり事後的な復旧対策を重視すべきだ、という意味です。つまりは、プロアクティブな措置とリアクティブな措置のバランスが大切なのです。事業ごと、またはITサービスごとに、災害に対するインパクトを定量化し、プロアクティブな対策とリアクティブな対策のどちらにより重点を置くか、ということを考える必要があるのです。

図３：事業へのインパクトのグラフ

守るべき事業やITサービスを識別したら、今度はその事業やITサービスにどのようなリスクがあるのか、そのリスクはどのような脅威が引き金になって起きるのか、ということを考えます。それがリスク・アセスメントです。リスクや脅威は環境によって様々です。書籍「サービスデザイン」では、表１のような例を載せていますので、参考にしてください。

表１：リスクと脅威の例

リスク	脅威
内部ITシステム／ネットワーク、PABX、ACDなどの損失	火災／停電／放火および破壊行為／洪水航空機衝突／ハリケーンなどの天候による損害環境災害／テロ攻撃／妨害行為／破滅的な渉外雷などの電気的渉外／事故に世売る破損低品質のソフトウェア
電子商取引サーバ、暗号システムなど、外部ITシステム／ネットワークの損失	前述すべてサービスに対する過度の要求インターネット・ファイアウォールなどに対するサービス妨害の攻撃暗号システムなどの技術的障害
データの損失	技術的障害／人的エラー攻撃アプレットなどのウィルス、悪質なソフトウェア
ネットワーク・サービスの喪失	ネットワーク・サービス・プロバイダ氏背酢に対する損傷およびアクセス拒否サービスプロバイダのITシステム／ネットワークの喪失サービス・プロバイダのデータの喪失サービス・プロバイダの障害
主要な技術スタッフおよびサポート・スタッフの非可用性	ストライキ／施設へのアクセス拒否／退職／病気・けが移動の困難
アウトソーシングされたITなど、サービス・プロバイダの障害	支払い不能などの破産／施設へのアクセス拒否サービス・プロバイダのスタッフの非可用性契約上のサービスレベルの不履行

要件が定まったら、それぞれの事業、ITサービスに対する継続性戦略をたてます。前述の通り、ITSCMの戦略は、予防的な措置と復旧的な措置のバランスが大切です。災害から受けるインパクトが小さいITサービスは、予防的な措置にあまり重点をおかなくてもいいでしょうし、たとえわずかでも停止することが許されないようなITサービスは、即座にサービスが再開できるようにあらかじめ準備しておかなければなりません。
ITIL v3 では、復旧オプションを以下のように分類しています。この復旧オプションの分類は、ITIL v2 の時代のものとは異なりますので注意してください。

１．手作業のワークアラウンド
ITサービスに頼っていた業務を、そのITサービスが再開されるまでの限られた期間だけ手作業にするというオプションです。データベースに記録していたデータを紙で記録するとか、一時的にノートPCの表計算ソフトを使う、といった手法が考えられます。
２．相互協定
本来は、同様の技術を使用する他の組織のITサービスを間借りするという手段のことを指します。しかしセキュリティ対策が叫ばれる現在、これは有効な手段ではありません。ただ、ごく限られたサービス（印刷機械を使わせてもらうとか、荷物運搬のためのトラックを使わせてもらうとか）では活用できるかもしれませんし、バックアップメディアの保管場所としての相互協定を結ぶということも考えられます。
３．段階的復旧
目安として、数日間または数週間の復旧の遅れに耐えることのできるサービスに対して適用される手段です。「コールド・スタンバイ」はこの段階的復旧の中に含まれます。例えば「災害が発生したら、電源やネットワーク設備が整っている空の施設を借り受け、そこに必要な機材を持ち込んで設置し、サービスを開始する」というような手段は、段階的復旧であるといえます。
４．中間的復旧
あらかじめ決められた時間内にビジネス・プロセスを復旧させる必要がある場合に適用される手段です。ITILではその時間的な目安が書かれていませんが、概ね24時間以上数日以内、といったところでしょうか。「ウォーム・スタンバイ」はこの中間的復旧の中に含まれます。「サードパーティのアプリケーション・サービス・プロバイダが提供するITサービスを借りてサービスを再開する」というような手段は、中間的復旧であるといえます。
５．高速復旧
目安として、24時間以内にサービスを復旧させる必要のあるサービスに対して適用される手段です。「ホット・スタンバイ」はこの高速復旧の中に含まれます。例えば「２次拠点を用意しておき、メインの拠点のバックアップを常に２次拠点に保持しておいて、災害発生時に切り替えて利用する」というような手段は、高速復旧であるといえます。
６．即時的復旧
「ミラー化」、「ロード・バランシング」、「サイト分割」などとも表現されるこの即時的復旧というオプションは、名前の通りサービスを即時に復旧させる必要がある場合に選択されます。即時的復旧の代表的な手段は、機器や設備の完全な二重化です。もちろん、データも二重化されている必要があります。このオプションは大変高価な選択肢です。たとえわずかでもサービスを停止させてしまうことが、ビジネスへの多大なる影響を与えてしまう、VBF である事業を保護するような場合にこのオプションは有効です。

ITIL v2 の時と比べると、「何もしない」という復旧オプションがなくなっていることが印象的です。さすがに「何もしない」というオプションは（たとえ本当にそれを選択したとしても）あまり歓迎される選択肢ではなかったのでしょうか。

「ITサービス継続性管理その２」へ続きます。