ユニット4：サービスレベル管理
4.7 SLAに照らしたサービス・パフォーマンスのモニタリ ング
SLAに照らしたサービス・パフォーマンスのモニタリング
SLAには、合意されたポイントでモニタまたは測定できないものを含 めるべきではありません。これは、将来の揉め事と、SLMプロセスの信 頼性喪失を避けるためです。パフォーマンスに対して測定可能なパラ メータを設定しないと、企業の信用が損なわれると同時に、多大なコ ストを負担する結果となる場合があります。
すでに導入されているモニタリングの能力を定期的にレビューし、ア ップグレードするべきです。これは、SLAの起草中または起草前に行 い、提案された目標値の妥当性確認を支援するためにモニタリングの 仕組みを導入できるようにするのが理想です。
モニタリングは、サービスに対する顧客の視点と合致していなければ なりません。これは非常に困難な場合があります。個々のコンポーネン トをモニタリングすることが、顧客に対するサービスの可用性を必ず しも保証するわけではありません。ある障害が他のサービスにも影響
を与えた可能性があったとしても、顧客は通常、インシデントが報告さ れたときに自分がアクセスしようとしていたサービスでの障害のみを 考慮します。これには注意が必要です。エンドツーエンドのサービスと してコンポーネントをモニタした場合にのみ、真の全体像を把握する ことができます。しかし、これを実現するにはコストがかかり、かつ困難 です。さらに、サービス目標値に違反があった場合にサービス・プロバ イダが警告を受けられるよう、ユーザはインシデントを直ちに報告す る責任を負っていることをユーザ自身に認識してもらう必要がありま す。
モニタリングにおけるサービスデスクの役割
多くの組織では、サービスデスクを利用して顧客の視点でのサービス の可用性をモニタします。これには、インシデント／問題を記録する画 面に特定の変更を加えることや、インシデントを記録する手順を厳格 に遵守することが必要となる場合があります。これらの課題に対して は、可用性管理プロセスを関与させて合意を得る必要があります。
サービスデスクは、インシデントの応答時間と解決時間のモニタにも よく使用されます。その場合も、データ収集に対応するために記録画 面を修正する必要があるかもしれません。また、コールの履歴を取る 手順を合理化し、それに厳密に従う必要があります。外部プロバイダ がサポートを提供している場合は、サプライヤ管理も関与します。
SLAに含まれるインシデント／問題の取り扱い目標値はすべて、サー ビスデスク・ツールで使用される値、およびエスカレーションとモニタ リングのプロセスで使用される値と同じにすることが必須です。そうで なければ、設定されたSLA目標値とは異なる値をモニタすることにな
ITIL v3 Intermediate Certification Level | Service Offerings and Agreements
Copyright © 2011, ITpreneurs Nederland B.V. All rights reserved.
90
My N otes
ります。その結果、データをかなり操作しないとSLA目標値が達成され たかどうかを示すことができず、モニタリング・プロセス自体が意味の ないものとなってしまいます。サポート・ツールは、データ収集に必要 なすべてのフィールドを含むように調整する必要がある場合がありま す。
画面を操作してから応答を受け取るまでの時間を示すトランザクショ ン応答時間も、追跡が困難です。エンドツーエンドの応答時間を追跡 することは、技術的に非常に難しい場合があります。そのような場合 は、次のことを実行します。
SLAに次のような記述を含める。「このSLAが対象とするサー
y
ビスは、高速な応答向けに設計されており、大幅な遅れが発 生することはありません。x秒以上の応答時間の遅れがy分以 上の間継続して発生した場合は、サービスデスクに直ちに報 告してください。」
報告期間内において、そのようなインシデントを何回まで許
y
容するかの目標値に合意し、これをSLAに含める。
「応答率の低下」というインシデント・カテゴリを追加する。そ
y
のようなインシデントがすべて正確に記録され、対応するサ ービスに関連付けられるよう徹底する。
SLAトランザクション応答時間に違反した場合に定型のレポ
y
ートを作成し、問題を修正するために問題管理を通じて調査 を推進する。
この体系的なアプローチは、モニタリングの技術的な問題の克服に役 立ちます。また、応答率の低下が即座に報告されることによって、遅延 を発生させる一時的なイベントの相互作用が直ちにに検知され、調査 されます。
サービスオペレーションの助言を得て、クライアント／サーバにおけ る応答時間の自動モニタリング・システムを導入することが理想です。
可能であれば、低いパフォーマンスを示すサンプリング・ツールや「ロ ボット」ツールを実装します。そのようなツールでは、ユーザが体験す る実際の応答時間が示されます。
SLAにRFCをアセスメントおよび実施するための目標値を含めた場 合、変更管理が使用するのと同じツールを使って変更管理関連の目標 値をモニタするべきです。また、変更記録画面とエスカレーション手順 もこれに対応するようにします。
幾つかの組織においては、「応答率の低下」がサービスに対するユー ザの認識の問題でもあることがわかっています。ユーザは特定のレベ ルの応答に慣れており、それを下回るとたちまち不満をもらします。「 サービスが遅くなったとユーザが感じたら、サービスは遅いのだ」と認 識するべきです。
SLMは、継続的サービス改善（CSI）の重要な原則です。以前は、多くの IT組織がSLAを、サービスの可用性やヘルプデスク・コールに関する独 立した合意セットとして単純にとらえていました。しかしそれは事実で はありません。今日では、事業は、ITがサービス・モデルに従うことを要
Student | ITIL v3 Intermediate Certification Level | Service Level Management
Copyright © 2011, ITpreneurs Nederland B.V. All rights reserved.
91
My N otes
求しています。これにより、事業とITの間で信頼性の高いパートナシップを築きやすくなります。また、ITは、すべての重要なビジネス・プロセ スを支援するようになっています。このことから、ITは各コミュニケーシ ョン・チャネルおよび意思決定プロセスの各レベルのすべてに関与す る必要があります。そのため、現在ではSLMが不可欠なのです。
SLMのステップ
SLMには、次のようなステップが含まれます。
IT組織が事業に対するサービス・プロバイダにならなければ、
y
不要となってしまうことを全面的に受け入れる。
事業のサービスレベル要件を決定する。
y
計画中、開発中、本番稼働中のサービスを含む、内部サービ
y
ス・ポートフォリオを定義する。このサービス・ポートフォリオ には、最終のサービス・パッケージの一部となるコンポーネン ト・サービスも含まれる。
ITがオプション、パラメータ、および価格設定とともに提示す
y
るあらゆるサービスとサービス・パッケージの詳細を示す、顧 客向けのサービス・カタログを定義する。
内部IT部門の関係を識別し、その関係における条件と責任に
y
ついて合意し、それらをOLAに文書化する。
外部ベンダとの契約上の関係を識別し、変更されたビジネ
y
ス・ニーズを外部委託契約（UC）が満たしているかを検証す る。満たしていない場合は再交渉する。
サービス・カタログをベースラインとして活用し、SLAについ
y
て事業と交渉する。
サービスレベルを定期的にモニタし、改善するために、SIPを
y
準備する。
IT組織は、SLMを導入し始めるとすぐに、「成功するIT」の古い定義がも はや当てはまらないことに気付きます。ネットワーク可用性の高いパ ーセンテージや顧客満足度調査での好成績は、もはや最終目標では なく、サービスレベルの目標値を認識するのに役立つ肯定的な測定 基準にすぎません。そこでITマネジメントは、SLMが根本的な変化の1 つであることに気づきます。今では最終目標は、顧客と事業の両者に よって合意されたサービスレベルなのです。そうしてITは、そのサービ スレベルを満たすかあるいは超えるために、構成され、運用され、管 理されます。サービスレベルは、すべてのIT活動が達成を目指さなけ ればならない究極の最終目標です。
ITIL v3 Intermediate Certification Level | Service Offerings and Agreements
Copyright © 2011, ITpreneurs Nederland B.V. All rights reserved.