サービス可用性――その評価手法を知っているか?：ITIL Managerの視点から（2/3 ページ）

[谷誠之，ITmedia]

■SOA（Serivice Outage Analysis）

図2：SOAの構造化アプローチ（画像クリックで拡大）

　日本語では、「サービス停止分析」となる。システム停止分析（System Outage Analysis）と書かれているものもあるが、意味はほとんど変わらない。現状では、SOAというと「サービス指向アーキテクチャ（Service-Oriented Architecture）」を指すことが多いため、詳しい文献をネット上で探るのは残念ながら困難である。

　SOAはその名前の通り、ユーザに提供するサービスを中心に、そのサービスが停止することになりうる根本原因を分析／改善することによって可用性を考える手法である。主人公はITではなく、サービスだ。サービスが中断される根本原因を、ITと少し切り離して考えてみよう、というわけだ。サービス中断の主たる原因は、もしかしたらITそのものではなく、運用面、決められたプロセス、手順、企業風土なのかもしれない。

　SOAの作業は、図2のような構造化アプローチをとる。一種のウォーターフォールモデルである。このアプローチそのものはコンサルティング業務などでは一般的なもので、目新しいものではない。言い換えれば、組織のサービス体系に対してきちんとコンサルティングしましょう、ということである。

　「改善機会の選定」とは、SOAの作業対象となるサービスを決定することである。対象となるサービスを事前に決定しておくことで、問題に集中することができる。

　「作業範囲の決定」は、今回の作業において対象となる領域、対象とならない領域を決めることである。例えばITインフラストラクチャを対象とし、手順やプロセスは対象としない、というようなことを決める。

　対象となるサービス、領域が決まったら次は「作業の計画」を行う。計画は、実際に作業を開始する数週間前から計画されることが望ましい。次のようなことを計画する。

1. 作業の開始日と終了日
2. 主要なマイルストーン
3. SOA作業のためのメンバー
4. 各メンバーの役割と責任
5. 分析に必要なデータの収集源
6. 作業を行うための場所や必要な機材（部屋、ホワイトボード、プロジェクターなど）
7. キーパーソンへインタビューするスケジュール

　現在の課題により集中的にフォーカスするために、作業の開始日と終了日との間隔は長くても6カ月以内にすることが望ましいとされている。