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

Vol.011 - 2009年03月24日（月2回発行）

今回は前回予告した通り、可用性管理の続きをご紹介します。可用性管理はサービスデザインにおける7つのプロセスの中でも比較的重要なプロセスです。中心となるのはサービスレベル管理（というより SLA）ですが、その SLA の項目の中でも特に重要なのが可用性、といえるでしょう。可用性は、ユーザの満足の核となるものなのです。

今回は、ITIL Foundation 試験には直接関係ないかもしれない話をします。ただ、実業務に対してはとても重要な概念ですので、ぜひ一度目を通してくださいね。

最初に、重要な概念をご紹介しましょう。これは ITIL v2 の頃にもあったのですが、特に重要なのであえてここでご紹介します。それは重要事業機能（VBF:Vital Business Function）と言う概念です。

通常企業内のITインフラストラクチャは、その企業においてビジネス上なくてはならない重要な事業にも、なくてもいい、とまではいかないがそれほど重要ではない事業にも、等しくサービスを提供しています。企業に潤沢な資金があり、IT資源に湯水のようにコストをかけられるのであれば話は別ですが、通常はそうはいきません。事業上重要なビジネス機能と、比較的重要性の低いビジネス機能に同じように可用性を確保するわけにはいかないのです。可用性マネージャは、事業上なくてはならない重要なビジネス機能をきちんと識別し、その部分のITサービスの可用性を特に高める必要があるのです。

この、事業上なくてはならない機能のことを、VBF というのです。

たとえば銀行の ATM における VBF は何でしょうか。特になくてはならない機能は、お金を引き出す、という機能でしょうか。あるいは振込みをする、という機能も、それがなければ ATM とは言えないかもしれません。その一方で通帳記入をするという機能は、使えなければ不便ですが必須の機能とは言えないでしょう。お金を引き出す際も、クレジットカードさえ受け付けることができれば、最悪の場合通帳記入ができなくてもとりあえずお金を出金することはできます。

そう考えると、ATM という IT資源に関して特に可用性を高める要素（ハードウェア）は、クレジットカードを扱うハードウェアの部分や、現金を扱う部分であるといえるでしょう。その一方で通帳を扱う部分の可用性は優先度が低い、と判断できるでしょう。

VBF をはっきりさせることによって、IT資源のどの部分の可用性をより高めるべきか、ということが明らかになります。もちろんこの決定は顧客との合意が必要で、合意した内容な SLA に反映されることになります。

VBF を意識して ITサービス（あるいはIT資源）の可用性を設計する場合には、次の４点に影響を与えると考えればいいでしょう。

• 高可用性：
  IT資源の障害が、そのIT資源を利用しているサービスのユーザに及ぼす影響を最小限に抑える、あるいは見えないようにすること。
• 耐障害性：
  ITサービス、コンポーネント、または CI の一部のコンポーネントに障害が発生した後も、適切に稼動し続けること。
• 継続的運用：
  ITサービスの計画的な休止時間を排除するアプローチまたは設計をすること。個々のコンポーネントまたはCIがメンテナンスのために休止している場合でも、サービスそのものは止めないこと。
• 継続的可用性：
  100％の可用性を達成する（またはそれに近づける）ためのアプローチまたは設計をすること。継続的可用性のあるITサービスには、計画休止時間も計画外休止時間も無い。

ただ、ここで気をつけなければならないのは、VBF とはあくまでも「事業上、なくてはならない機能のことを指す」ということです。小売店だったら「商品を販売する」という機能が VBF です。「なくてはならないITサービス」や「なくてはならないIT資源」のことではありません。くれぐれもご注意ください。

さて、ITサービス、または IT資源の可用性は、その ITサービスが導入され稼動を始めたときから廃止されるまで、まさにITサービスの「ゆりかごから墓場まで」ITサービスのライフサイクル全体に関わることになります。導入したばかりだから可用性は低くてもいいとか、もうすぐ廃棄するから稼働率が低くなるのは仕方ない、とは言っていられません。SLA に書かれている可用性の目標値を達成するために、常に活動をし続けることになります。その主な活動内容は、次の通りです。

• 事業と連携して VBF を決定する。その際、ITサービス継続性管理（ISCM）とも連携を図る。
• ITサービスをサーポートする ITインフラストラクチャそれぞれの可用性、信頼性、及び保守性の目標値を定義し、SLA、OLA および UC においてその目標値を文書化し、顧客と合意する
• 新規、または強化されるITサービスに対する事業からの可用性要件を決定し、その可用性や復旧に関する設計基準を策定する
• ITSCM と連携して ITサービスおよびIT資源の障害から生じるインパクトを特定し、そのインパクトが高い場合にはその非可用性を防止または最小化するための対障害弾力性を提供する
• ITコンポーネントの可用性、信頼性、および保守性のモニタリングと傾向分析を行う事業、ユーザおよびITサポート組織の観点を反映する可用性、信頼性、および保守性の測定と報告の手順を確立する

可用性管理のプロセス活動は、まさに PDCA といえるでしょう。VBF を見極め、その機能をできるだけ停止させないように優先度を定めて必要十分な可用性要件を決定し、その可用性を維持するための方法を計画・実行して、定期的にモニタリングし、必要であれば改善する。そのどれもが重要な要素ですが、なくてはならないのが測定と評価です。これらの測定値や評価結果は、ITサービスやIT資源を管理したり改善したりするために必要不可欠な要素です。

また、可用性として何を測定するのか、ということもおろそかにはできません。ITサービス可用性の測定と報告がひいては事業サービスの可用性を測定することにつながり、最終的に組織と事業全体の利益に大きな影響を与えるからです。そのため、測定値は有意義で価値を付加するようなものでなければなりません。

可用性の測定を行う時や、測定結果を報告する時には、次の点を考慮します。

• 何を測定するのか
• その測定結果は、どの事業活動に関係しているのか
• 測定結果の受け取り手は誰か
• 受け取り手によって、その測定結果がどのように利用されるのか

繰り返しますが、測定結果は「役に立つ」ものでなければなりません。役に立つとは、その測定結果を受けて改善すべきところがわかり、どう改善すべきかがわかり、なぜ改善すべきかがわかる、ということです。それらがわかるためには、測定結果の中に次の３つの要素が含まれている必要があります。

もう少し詳しくご紹介しましょう。まずは、事業の側面からです。

事業の面としては、ITサービスの可用性が事業、特に VBF に悪影響を与えなかったか、事業がITサービスの非可用性によって停止することがなかったか、が重要になります。当然マイナスのイメージだけでなく、目標値をちゃんと達成していれば、可用性は事業に対してプラスの影響を与えたことになります。その、OK か NG かの判断基準は、なんといっても SLA に記載された目標値です。その目標値と実際の測定値とを比較することで、達成度が算出されるわけです。ITサービス・プロバイダは、目標値に対して達成度がどのようになっているのか、定期的なサービス・レビュー・ミーティングで事業側（顧客側）に定期的に報告します。

さて、その目標値ってのがクセモノです。どうクセモノなのかは、次で解説しましょう。

ITの世界では昔から、可用性なるものに大変注目してきました。何も、今に始まったことではありません。そして従来の可用性を示す測定値の基本は、稼働率です。率です。つまり、割合です。

例えば、

• 可用性の割合（合意したサービス時間のうち、何％稼動していたか）
• 非可用性の割合（合意したサービス時間のうち、何％使えなかったか）

が２大巨頭です。

ただこの割合ってのは、気をつけなければなりません。

例えば
サービスレベル目標値：99.5%　　　サービスレベルの達成度：99.0%
こう見たら、サービスレベルはほぼ達成しているように見えます。なにせ、0.5% しか違わないのですから。しかしこれは見方を変えれば、
目標の非可用性の割合： 0.5%　　　実際の非可用性の割合：1.0%
であるともいえるわけです。ほら、こうしてみたら、非可用性は目標値の倍になっています。

また、可用性を測るためのサンプルの個数も重要です。例えば日単位で可用性を計測しているような場合、サンプルが100日間しかなくて、そのうち使えない日が1日あったとすると、もう可用性は 99% になってしまいます。目標値 99.5% なんて、100% と言っているのと同じになってしまいます。

では、時間はどうでしょうか。可用性を示すふたつめの重要な単位は時間です。前回ご紹介した MTRS や MTBF、MTBSI の単位は時間です。また、1年365日・24時間無停止を求められているITサービスの稼働率を「99.99%」と表現したら、それはよく「50分間」と言い換えられます。

ただ、その50分間の停止も、ピーク時（事業のまっただ中）に50分間停止するのと、閑散期（夜中とか）に50分間停止するのとでは、ユーザに与えるインパクトはまるで異なります。さらに、1回だけ50分間停止するのと、1分の停止が1年の間に合計50回（週に1回！）あるのとでは、やはりインパクトの度合いは変わってくるでしょう。

従来の可用性とは、このような「割合」や「時間」で表すのが主でした。しかし、ユーザの立場からすると、それだけでは不十分なのです。すなわち

• 障害の継続期間（1回あたりどれほど使えないのか）＝ MTRS
• 障害頻度（何回障害が発生したのか、障害と障害との間隔はどの程度か）＝MTBF、MTBSI

に加えて、

• 障害のインパクト（その障害でどの程度の影響を受けたのか）

といった尺度で、可用性を考えなければならないのです。

障害のインパクトは、サービス非可用性の真の指標です。そのため、障害のインパクトの記録は特に慎重に行わなければなりません。

ITIL v3 では、この障害のインパクトにふたつの考え方を導入しています。ひとつは「ユーザ時間損失によるインパクト」であり、もうひとつは「ビジネス・トランザクションによるインパクト」です。

ユーザ時間損失によるインパクトとは、次の計算式で割り出します。
ITサービス停止時間　×　停止したことでインパクトを受けたユーザ数
これによって、可用性をユーザの生産性の損失として報告したり、可用性のパーセンテージをユーザ視点で計算したりすることが可能になります。

また、上記の計算式に「失われた生産性を回復させるコスト」を含めることも出来ます。そちらのほうが現実的かもしれません。

ビジネス・トランザクションによるインパクトは、ITサービスが停止している間に処理することが出来なかったビジネス･トランザクション数で算出します。事業を行っている時間帯や曜日などによってビジネス・トランザクションの処理数は違うはずです。単なる停止時間の測定だけでなく、喪失したビジネス・トランザクションの数を数えることは、障害が事業に与えるインパクトを正確に算出することに役立ちます。

「ユーザ時間損失によるインパクト」と「ビジネス・トランザクションによるインパクト」のどちらの手法を利用するかは、事業の目的やニーズによって異なります。

事業へのインパクトが必ずしてもユーザへのインパクトにつながる、とは限りません。ユーザに直接影響を与えない部分（例えば大量の処理を自動化している部分）に障害が発生し、ユーザには直接影響はないものの、事業に対しては財務的インパクトを与えている、というパターンもありえます。

しかし、逆はありえます。障害がユーザに与えるインパクトは、たいてい事業に深刻なダメージを与えます。上記の「ユーザ時間損失」や「ビジネス・トランザクション」の他にも、ユーザがITから受ける印象、という数値化できないインパクトもあるでしょう。信頼のおけないITだ、と思われることは、すなわち信頼のおけない事業だ、と思われることに等しいのです。

可用性管理では、「技術が事業をサポートする方法を理解して初めて、可用性の改善を始めることが可能である」というのが基本原則です。単に各IT資源の可用性を高めるだけでは、真の可用性向上とはいえません。ユーザが何を求めているか、事業が何を求めているかということを理解しなければならないのです。その求められているITサービスが利用したい時に利用できる、ということが大切であり、そのために稼働中のITサービスの全てのコンポーネント（システムやネットワーク、アプリケーション、データなど）が合意したサービス時間の中で安定して利用できることが必要であるということです。