ITIL サービスデザイン − 可用性管理１

今回は「サービスデザイン」の4つ目のプロセス、「可用性管理」のお話です。可用性管理には数多くの用語や計算式などが登場するだけでなく、ITILのライフサイクルにおいて重要な位置を占めるプロセスです。そのため可用性管理については、合計３回に分けてお話を進めていく予定です。

基本的なコンセプトは、ITIL v2 とあまり変わりません。可用性管理は文字通り、ITサービスの可用性を管理するプロセスです。ここで言う可用性には、ITインフラストラクチャの「壊れにくさ、障害の発生しにくさ」のことだけでなく、ITサービスの品質の高さも含めます。サービスを利用する側にとってそのサービスが利用しやすいかどうか、利用した結果どのような価値を手にすることが出来るのか、といったことを数値化します。そうすることでハードウェアの耐久性や故障しにくさなどと同様に、可用性の目標値を設定できるようになり、その目標値を達成するための活動を行うことができるようになるのです。この活動を管理するのが可用性管理の活動です。

ITIL書籍「サービスデザイン」を見てみると、可用性管理の目標は次のようなものがあげられています。

• 現在および将来のビジネス・ニーズを反映する、適切で最新の可用性計画を作成、維持する
• 可用性に関連する全ての課題について、事業とITのその他の全ての領域に対する助言と手引きを提供する
• サービスとリソースに関連する可用性のパフォーマンスを管理することによってサービスの可用性が合意された全ての目標値を満たすか、それはそれらを上回るようにする

言い換えれば可用性管理とは、顧客やユーザに対して一定レベルの可用性を提供し続けるための活動です。具体的には、事業ニーズを満足させるために導入する ITサービスに対して、費用対効果が高く、顧客やユーザに対してSLAで合意した可用性レベルを合意したコストで実現したり、維持したりすることです。

前回、本コラムのキャパシティ管理でも触れましたが、事業を取り巻く環境は常に変化しています。そのために事業戦略は事業の現在の状況ばかりでなく、事業が進む将来の状況を見据えてそれを考慮に入れた上でITサービスの導入や変更の計画を立て、変化に対応できるようにする必要があります。可用性管理もその中に含まれます。すなわち、現在の ITサービスの可用性だけでなく、多少事業戦略が変わったとしても（ITサービスに求める可用性用件が多少変わったとしても）柔軟に対応する力を持っていないといけないのです。

可用性管理が対象とする範囲は、ITサービスとそれらを支えるコンポーネントすべてです。言い換えれば、ITサービス、およびそのITサービスを提供するのに必要なインフラストラクチャの設計、導入、測定、管理、改善全体を可用性管理プロセスで監視しなければなりません。おのずと数多くのITサービスとインフラストラクチャを対象とすることになります。その各コンポーネント単位で、利用目的に応じた可用性の目標値を定めます。目標値はプロバイダと顧客やユーザとの間で合意する必要があり、その結果は SLA に反映されることになります。

この SLA に定められた可用性の目標値を達成するために、プロバイダは各ITサービスやインフラストラクチャ単位に可用性を維持する手法を設計し提供します。さらに ITサービスを提供し続ける間、目標値が守られているかどうかの監視を行い、必要であれば可用性を維持する手法を改善することになります。

目標値はユーザにとってわかりやすく妥当なこと、顧客にとって費用対効果が高いこと、プロバイダやサプライヤにとって技術的にも実現可能であること、が必要です。

目標値を設定するときには次の5つの点を参考にします。

• 現在のビジネス・プロセスとそれらの運用及び要件
• 将来の事業計画と事業要件
• サービスの目標値、および現在のITサービスの運用と提供
• ITインフラストラクチャー、データ、アプリケーション、および環境、そしてそれらのパフォーマンス
• サービスとその使用に関連する事業へのインパクトおよび優先度

ITサービスを提供する上で可用性はユーザにとって業務にかかわる大切なことです。可用性の目標値が確実に継続的に守られていることは、ユーザにとっては「あたりまえ」のことだからです。身近な例では、出勤時や退社時に公共交通機関がつかえるのも「あたりまえ」だし、銀行に行けば ATM からお金を引き出すことができるのも「あたりまえ」です。ユーザはそんな「使えてあたりまえ」のものに障害が起きると不便を感じ、長時間利用が出来なくなると苦情を訴えます。

こうしたことを避けるため、可用性管理のあるべき姿を明確にしなければなりません。具体的には、次の4点が挙げられています。

• 全ての運用中のサービスと技術、中でもとりわけSLAに含まれるものに適用するべきである。また、事業上、重要度が高いと考えられるITサービスについては正式な SLA の有無にかかわらず適用する
• 全ての新しいITサービスと、サービスレベル要件（SLR）や SLA が設定されている既存サービスに適用するべきである
• 正式な合意の策定に先だって、全ての支援サービス、およびITサポート組織を形成する（内部および外部の）パートナとサプライヤに適用すべきである
• に影響を与える可能性のあるITサービス、コンポーネント、およびサポート組織について、トレーニング、スキル、プロセスの有用性、手順、およびツールを含むあらゆる側面を考慮する

可用性管理プロセスでは、運用中の全てのITサービスとインフラストラクチャの可用性が、SLA で合意された目標値を満たすことが大切だと述べてきました。これは、新規に導入されるITサービスにも、ITサービスが変更される時にも適用されます。つまり、システムに何らかの変更が生じても既存のシステムのサービスが低下することの無いようにしなければなりません。

それを満足するために、可用性管理では「リアクティブな活動」と「プロアクティブな活動」を含みます（図1）。この考え方は ITIL v3 で初めて採用された考え方です。

図１：「リアクティブな活動」と「プロアクティブな活動」

ITIL書籍「サービスデザイン」では、リアクティブな活動とプロアクティブな活動について次のように述べられています。

リアクティブな活動：

非可用性を伴う全てのイベント、インシデント、および問題のモニタリング、測定、分析、および管理が含まれる。これらの活動は、主に運用上の役割の中に含まれる

プロアクティブな活動：

可用性のプロアクティブな計画立案、設計、および改善が含まれる。これらの活動は、主に設計と計画立案の役割の中に含まれる。

簡単に言えば、リアクティブな活動とは「非可用性の原因を取り除くための活動」であり、プロアクティブな活動とは「将来の可用性を保証するための活動」だと言えます。

一般的に可用性は、その目標値や実測値を割合で表現します。可用性の計算は（式１）の通りです。表現の仕方は ITIL v2 の時と比べてわずかに異なりますが、意味は同じです。重要なのは、停止時間の中に「あらかじめ予定されていた停止」は含まれない、ということです。合意済みサービス時間（AST：Agreed Service Time）内に停止した時間だけを式に含めるようにします。ただし、総停止時間も記録し報告するほうがよいでしょう。

可用性の中身は、大きく「信頼性」と「保守性」に分けられます。

「信頼性」とは、顧客やユーザに提供されるITサービスやインフラストラクチャがいかに中断せず稼動し続けるか、つまりいかに壊れにくいかということを示します。信頼性を表す数値は「平均サービス・インシデント間隔（MTBSI）」または「平均故障間隔（MTBF）」という形で報告します（式２）。

一方「保守性」とは、障害が発生したときに、どれだけ早く効果的に通常の稼働状況に戻すことが出来るか、つまりいかに早く直せるかということを示します。保守性は、平均サービス回復時間（MTRS）という形で報告します（式３）。

ITIL v2 の頃の平均修理時間（MTTR）と同じ意味ですが、用語が異なっています。MTRSの停止時間はサービス、コンポーネントが使用不能である時間を全て含みます。そのため、

• 記録時間
• 対応時間
• 解決時間
• 物理的な修理または交換の時間
• 復旧時間

などの要素を含みます。

さらに、サードパーティのサプライヤが契約条件を満たす能力が「サービス性」です。この契約には、プロバイダへの支援的なサービスや構成アイテムに対して合意したレベルの信頼性、保守性または可用性が記載されます。

今回は、可用性管理の目標や達成目的、適用範囲、事業に対する価値や基本概念についてお話をしました。次回は、可用性管理のプロセス活動の手法や技法、重要業績評価指標などについてお話をする予定です。お楽しみに。