 |
||||||||||||||
|
||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||
|
||||||||||||||
| サービスレベルの設定 | ||||||||||||||
|
サービスレベルは、過去の実績やベストプラクティス、場合によってはユーザ調査結果などを突合して設定するが、基本的には実績を最優先する。 サービスレベルを設定する際は、サービスレベルの改善を視野に入れないように注意する必要がある。サービスレベルを討議する段階で親会社は、情報システム子会社に何らかの要求（障害発生の減少など）をしてくるのが常である。 しかし、これらの要求を聞き入れて「あるべき姿」のサービスレベルを設定しても、実現が難しいうえにコミットができない。まずは「現状の姿」でサービスレベルを設定して、サービスレベルの改善はSLMを軌道に乗せた後、評価・分析に基づいて実施することが理に適っている。 |
||||||||||||||
| 実測値の収集 | ||||||||||||||
|
サービスレベルは評価項目ごとに実測値（実際に測定した過去データ）を使用し、達成可能な水準を視野にいれて目標値を設定する。 実測値の収集段階では、その測定や評価の方法についても検討する必要がある。システムの「可用性」を例に測定方法みてみよう。 昨今はシステム構成が複雑化し、明確に構成要素を分解できないものも少なくない。そこで、一般的に採用されているのは、停止時間の扱いを「システム全体の停止時間」または「いずれかのシステムが停止した時間の合計」のどちらかに設定する方法である。分散システムやその他のケースでは単純にシステムコンポーネントの平均値を採用する場合もある（図3）。  図3：複数のシステム・コンポーネントにおける可用性の計測の例（注1） 出典：ITR （画像をクリックすると別ウィンドウに拡大図を表示します）
※注1：
いずれの場合も影響度の低いプロセスや一部のアプリケーション機能の停止は含めない。
しかし、ここでは正しい測定方法の定義に過度に時間を割く必要はない。SLMの目的はサービスレベルを管理して改善する点にあり、一定の基準で比較できるデータがあれば運用できるからだ。 ただし選択の余地がある際は、ユーザ部門が直感的に判断しやすい値を算出しておくことが望ましい。 例えば、イントラネットにおいてWebサーバ、アプリケーションサーバ、データベースサーバのいずれかが停止するとユーザはサービスを利用できなくなる。この場合、システム全体を構成するシステムコンポーネントの可用性の平均を求めるよりは、直列n階層システムの測定方法を用いる方が適当である。 |
||||||||||||||
| SLAの記述 | ||||||||||||||
|
サービスレベルの設定とその計測、評価、報告に関する手順が定まれば、実際にSLAを作成する段階となる。 SLAにはサービスメニューやサービスレベルに関する条項のほかに、方針、適用対象、役割分担、各種条件などが記述される。中には、達成度合いに応じてボーナスやペナルティを設定するケースもあるが、国内の情報システム子会社においては一般的でない。 ここでの着目すべき点の1つに、各種条件の設定があげられる。サービスレベルを維持するには特定の条件が必要であることを明示しておかなければならない。今はよくても今後、システム環境や運用条件が変わる可能性があるからだ。 これには「PCサポートは標準機に限定する」といった業務特性上の条件や、「メールサービスのサービスレベルはアカウント数が現状の±20%を超過する場合は適用外とする」といったキャパシティ上の条件があげられよう。 各種条件は保険契約でいう免責事項に近いものであり、条件が曖昧であればSLAが情報システム子会社にとって過度に不利益なものになる危険性がある。逆に条件が厳し過ぎると、親会社にとって柔軟な対応が期待できなくなる。 現実的な落とし所は親子関係や企業文化に左右されるが、調整・交渉にあたってこれらの条件を洗い出しておくことは無駄ではない。 |
||||||||||||||
| 利用者との合意 | ||||||||||||||
|
SLMは親会社が要請する場合もあれば、情報システム子会社が起案して自主的に実施するケースもある。いずれの場合も、まずはSLAを合意してマネジメントサイクルを実施することを最初の目標としなければならない。記述内容は後々改訂することができる。まずは、はじめてみることが肝心である。 実際のところSLAを要請された場合、抵抗感を抱く情報システム子会社や外部委託先は少なくない。業務活動を監視され、成果ベースのコミットメントを求められるのだから当然のことである。 しかし、SLAは情報システム子会社にとって不利益な面だけではない。これまで曖昧だった業務分掌や条件を明確にすることで業務環境を改善できる可能性もある。 例えば、これまではサービスデスクが時間外対応をしても、それまでは当然のことと受け止められていたかもしれない。しかし、ひとたびSLAでサービス提供時間について合意すれば、以降は夜中に電話を受ける必要はなくなる。一時的に不満はでるだろうが、ユーザ側にIT業務の特性（時間的特性や難易度など）を理解してもらうひとつの機会にもなるだろう。 また、サービスレベルがコストと連動していることをユーザに理解してもらう意義も大きい。可用性の向上を要求されたとしても、一定の数値目標を達成するにはシステムを冗長化する予算が必須であると訴えることができるだろう。 国内のIT部門や情報システム子会社はユーザに対する発言力が必ずしも十分でなく、ユーザもまた甘えたり依存したりするケースは少なくない。曖昧な業務分掌を明確にし、目に見えない品質を可視化することで、ユーザに対する適切な発言力を得られる。実は、そのようなところにもSLAを策定する意義はある。 |
||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
