当レポートは、前編、中編、後編と連載した「エンタープライズ・モニタリングのつぼ」の続編です。「エンタープライズ・モニタリングのつぼ」では、ＩＴインフラストラクチャーのネットワーク、ハードウェア、ソフトウェアの各種リソースのモニタリングについて解説しました。このレベルでのモニタリングが実現した場合、モニタリングの先に見えてくる次のステップが、SLAとサービス管理です。SLA、サービスレベル管理のより詳細な情報には、ＩＴＩＬ（ Information technology Infrastructure Library：参照記事）のドキュメントがあります。ここでは、ＩＴＩＬに記述された運用プロセスのベストプラクティスを参考にしながら、具体的な事例も交えてSLA、サービスレベル管理について説明していきます。
そもそも、サービスレベルとは？
コンピュータ・システムとは、最終的にはエンド・ユーザーに対しあるサービスを提供するものということができます。これを逆にいえば、エンド・ユーザーから見たコンピュータ・システムとは、利用できるサービスそのものにほかなりません。この観点からはコンピュータ・システムの価値は、提供されるサービスの内容とその品質ということになります。このようにサービスの品質は、コンピュータ・システムの存在や価値を決定するものであり、このエンド・ユーザーに提供するサービスの品質のことを一般にサービスレベルと呼びます。
身近なサービスレベル
コンピュータ・システムのサービスレベルはわれわれの日常生活に、身近に存在しています。銀行などのATM（現金自動預け払い機）を例に取ってみます。ATMには営業時間が定められており、かつ営業時間帯によって利用できるサービスが異なる場合があります。例えば休日・深夜は、現金引き出しはできるが、振り込みはできないなどです。あるサービスが提供される時間帯のことをサービス時間といい、サービスレベルの1つです。またATMを操作して一定時間何も応答がない場合は、ユーザーは故障と見なし、係の人を呼んだりします。このATMの応答時間もサービスレベルといえます。ユーザーは、サービスレベルに応じて行動を決定したり、行動の選択をします。例えば「休日に現金が必要な場合、Ａ銀行のATMでは休日の取引ができないので、Ｂ銀行のATMを使用する」とか「1分間ATMの応答がなかったので、係の人を呼んだ」とかです。
このようにユーザーから見た場合、サービスレベルは高いに越したことはありません。しかしサービスレベルとＩＴコストの関係は、一般に対立関係にあり、しかも図1に示すようサービスレベルとコストは単純な比例関係にはありません。より高いサービスレベルを求めるとより高いコストが掛かります。平日8時間だったサービス時間を休日・深夜も含む24時間にした場合、サービス提供側は、休日・深夜のサポート体制を敷いたり、システムの冗長化やオンライン・バックアップの実施など、ユーザーの想像以上に膨大な追加コストが掛かる場合があります。このように得てして対立関係に陥ってしまうサービス提供側とサービス利用者側の間で、サービスレベルに関する取り決めをするサービスレベル・アグリーメントという概念が生まれました。
・サービスレベルを上げるためにはコストも上がる
・サービスレベルとコストは単純な比例関係ではない
SLA＝両者が達成目標に合意
サービス提供側とサービス利用者側で、そのサービスレベルの達成目標について両者間が合意することをサービスレベル・アグリーメント（以下SLAと呼びます）といいます。
SLAの適用事例としては、アウトソーシング・ベンダが提供する各種のＩＴサービスの品質を保証するため、契約の中に取り込まれた例が多く見られます。さらに最近は、アウトソーシング・ベンダとユーザー企業間といったＢｔｏＢのSLAだけではなく、消費者と企業間といったＢｔｏＣのSLAを契約に取り込む例も増えています。SLAを守れないことをSLA違反（ブリーチと表現する場合もあります）もしくはSLA未達といいます。SLA違反になった場合、ペナルティを科す場合もあります。ペナルティは、利用料金の減額など金銭的なものや、アクションプランの策定・実施などがあります。
SLAを採用する目的として、
- 高品質のサービスレベルの維持
- サービスレベルを明確にすることでユーザーの利便性が向上
- サービス提供側、サービス利用者側それぞれの責任範囲の明確化
効果として、
- サービスレベルに見合ったコストの明確化
- 合意と達成、報告と改善を通じ現行システムの問題点、課題点の把握
- サービス提供側とサービス利用者側への信頼関係の構築
が挙げられます。SLAを採用することにより、上記のような効果が期待されるため、SLAは企業間の契約だけではなく、社内システムなどにも有効な手法として考えられ始めています。
サービスレベルをマネジメントする
SLAは、あくまでサービス提供側とサービス利用者側との合意によって形成されます。そのため、両者間でSLAの管理プロセスについても取り決める必要があります。SLAの契約や合意内容の管理、サービスレベル値を計測する技術的手法の確立、サービスレベルを評価・改善するＰＤＣＡサイクル運用体制などといったSLAに関する管理プロセスのことをサービスレベル管理またはサービスレベル・マネジメント（SLM）といいます。
サービスレベル管理のプロセスの一例を図2に示します。
サービスレベル管理の各プロセスは以下のようになります。
１．SLM開始
SLA計画では、サービス提供側とサービス利用者側それぞれの代表者の設置、体制整備、報告やレビューのプロセス、スケジュールなどを立案します。立案したSLA計画にのっとりSLMを実施していきます。
２．SLAの実装
2.1 サービスカタログ作成
サービスカタログと呼ばれるSLA交渉の叩き台資料を用意し、ＩＴサービス全体像の把握やサービス優先度を付け、共通認識することを目的とします。サービスカタログの例を表1に示します。このようにユーザー部門別に必要なサービスの洗い出しを行います。
| 部門＼部門 | 営業1課 | 営業2課 | 営業3課 | 人事 | 総務 | 広報 | 購買 |
|---|---|---|---|---|---|---|---|
| 人事オンライン | ○ | ||||||
| 受発注業務1 | ○ | △ | ○ | ||||
| 受発注業務2 | ○ | ○ | ○ | ||||
| Webポータル | △ | △ | ○ | △ | ○ | ||
| 電子メール | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
| ヘルプデスク | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
| 表1 サービスカタログの例 | |||||||
2.2 SLAドラフト作成
測定方法、収集方法、評価方法など技術的課題を検討した、SLA項目のドラフトを作成します。ドラフト段階では、目標値には実測値や現実的期待値を入れます。
2.3 部門間交渉
ドラフトをベースに各SLAにつき関係者と交渉します。
2.4 契約・合意のレビュー
SLAを支える契約・合意、前提条件や免責事項についてレビューを実施します。SLA契約は基本的にサービス提供者とサービス利用者間の契約であり、企業内部の部門間契約である運用レベル契約（OLA：Operational Level Agreement）と、外部企業との契約である基盤契約（UC：Underpinning Contract）の2つがあります。SLAサポート構造を図3に示します。
多くのSLAは通常、他部門や外部のサービス提供業者によって支えられる
- SLAの前提としての、OLAやUC締結が望ましい
- OLAで承認された以上のサービスレベルをSLAでコミットする事は難しい
- SLA締結時に、OLAやUCの確認・見直しが必要
2.5 SLA合意
合意したSLAの文書化、周知を行います。
３．進行中のプロセス管理
3.1 モニタリング
SLA項目に従ってモニタリングの設定と実施を行います。
3.2 レポーティング
モニタリングの取得結果に基づいてレポートを作成します。レポートには主に次の2つに分類されます。
SLA違反レポート
定期運用レポート
3.3 結果レビュー
作成されたレポーティングに対し結果レビューを実施します。ここではSLA達成状況やSLA違反についてレビューします。
４．定期レビュー
4.1 SLMプロセスレビュー
ビジネス状況との整合性や達成状況、効率面の見直しを行います。
4.2 SLA／OLA／UCの見直し
各項目の目標値の見直し、前提条件確認、契約・合意内容の改訂を行います。
このレビュー結果を踏まえ、2.SLAの実装から繰り返します。
このようにサービスレベル管理のプロセスは、サービスレベルを評価・改善するPDCAサイクルを通じて、スパイラルに進めていくことになります。
「SLA項目の選定」が効果に大きな影響を
SLAを成功裏に実現するためには、SLA項目の選定が鍵になります。SLA項目として望ましい基準を挙げ、その理由について説明します。
SLA項目の選定基準
- ユーザーの立場で実効性があるもの
- 客観的な視点で定量データとして測定可能なもの
- 自動的に測定可能なもの、および測定結果の保存・収集が容易なもの
基準の理由
- キャッシュ・ヒット率やディスクＩ／OなどOSレベルのパフォーマンスやプロセスダウンなど単一コンポーネント障害はエンド・ユーザーの立場からSLAとして望ましいといえません。CPU使用率もエンド・ユーザーから見た場合、サービスに与える影響が明確になっていない場合が多く、適切とはいえない場合があります。ただし実際には、エンド・ユーザーにサービスを安定的に提供していることを示す指標の1つとして、CPU使用率をSLA項目として採用している例は多く見られます。
- 例えば、ユーザーに対するアンケート調査の結果での、漠然とした満足度はSLA項目として望ましいとはいえません。特定画面における応答時間の体感調査などは、アンケート結果でもSLA項目になります。一般的に数値データとして測定が困難なものは、SLA項目として望ましくありません。
- 測定するのに、毎回手動での測定が必要だったり、オペレータ操作が必要なものは、運用面を考慮するとSLA項目として望ましいとはいえません。また測定結果の保存、収集が容易なものが望まれます。測定データがあまりに巨大だったり、保存・収集に向かないものも望ましくはありません。
代表的なSLA項目
具体的なSLA項目は、可用性に関する項目、パフォーマンスに関する項目、キャパシティとデータ保全に関する項目、およびその他の項目に分類できます。その他の項目としては、ヘルプデスク関連やセキュリティ関連の項目が含まれます。ここでは前述の基準にのっとって個々の分類で代表的とされるSLA項目を挙げて、それぞれについて説明します。
１．可用性（アベイラビリティ）
可用性（アベイラビリティ）とは、特定のサービスをユーザーがどの程度利用できていたかの指標です。可用性に属するSLA項目として以下が挙げられます。
サービス時間：ユーザーが利用できるサービス時間帯。
サービス稼働率：ユーザーが特定のサービスを利用できる確率。一般には、
（サービス提供時間−停止時間）÷サービス提供時間100［％］
で求められます。24時間365日体制の運用を基準に考えると、99.99％のサービス稼働率を目標とする場合、停止時間は1年間で約50分以内に抑える必要があります。
障害回復時間：障害を検知してから、障害が回復してユーザーがサービスを受けられるまでの時間。SLAでは、平均回復時間（MTTR：Mean Time To Repair）だけではなく、回復時間の上限を定めることもあります。ほかに平均故障間隔（MTBF：Mean Time between Failure）を定めることもあります。
２．パフォーマンス
システムの視点からのパフォーマンス項目は多数ありますが、SLAではユーザーの視点からの測定が不可欠とされます。その代表例を挙げてみます。
応答時間：エンド・ユーザーのある入力から結果が戻ってくるまでの時間です。理想的な項目の1つですが、エンド・ユーザー側に測定用のソフトウェアが必要になる場合もあります。
ターンアラウンドタイム：ある要求の開始から終了するまでの時間です。バッチジョブなどのパフォーマンスに用います。
スループット：単位時間当たりの処理数です。
パフォーマンスの目標値設定として、平均値だけではなく、分散も考慮します。例えば 測定結果の90％がある目標値以内にあるといったSLA設定もあります。
また、ピーク時と通常時に分けてパフォーマンス目標値を設定する場合もあります。
３．キャパシティとデータ保全性
ユーザーの視点からキャパシティやデータ保存に関する項目がSLAとして設定されることがあります。
ディスク容量：あるユーザーのディスク容量を保証します。
ディスク使用率：ディスク使用率が一定値を超えないよう保証します。
バックアップ頻度：あるデータのバックアップを取得する頻度を定めます。
バックアップデータ保管期間：バックアップしたメディアを何世代保管するか定めます。
４．その他
ヘルプデスク・サービスデスク：ヘルプデスクやサービスデスクに対するSLAを設定する場合があります。平均呼び出し回数、問題解決時間、初回コール解決率などがあります。
セキュリティ：セキュリティに関するSLA項目として、ウィルスチェックの有無や頻度、アクセス制御の実施、監査ログの取得とチェック、侵入検知、セキュリティパッチの適用と頻度などが定められることがあります。
表2にSLA項目の一例を示します。
| 項目 | 説明 | ||
|---|---|---|---|
| 可用性 | サービス時間 | ユーザーが受けるサービス提供時間ただし、 メンテナンス時間 は除く | 24時間365日 |
| サービス稼働率 | (サービス提供時間−停止時間）÷サービス提供時間100［％］ | 99.7% | |
| 障害回復時間（MTTR） | 障害を検知 した時間から、障害が回復してユーザーがサービスを受けれるまでの時間 | 1時間を越えないこと | |
| 障害通知時間 | 障害が発生してから、ユーザーに障害が発生したことを通知するまでの時間 | 30分を超えないこと | |
| パフォーマンス | 応答時間 | 一定時間(1時間)内の全トランザクションの95%が含まれる応答時間 | 3秒以内（非ピーク時）5秒以内（ピーク時） |
| 保全性 | データ・ログの保全性 | システム上のデータベース、ログの保持期間 | ログ7日間データベース31日間 |
| 表2 サービスレベル・アグリーメントの一例 | |||
SLA評価とレポーティング
SLA評価では、SLA達成評価やSLA目標値の妥当性の評価や測定値のトレンド解析を行います。トレンド解析により現時点はSLAを満たしていても、将来SLA違反しそうな項目の予想をします。また単にSLAの達成状況、違反状況の評価だけではなく、日次、週次、月次といったある頻度で測定値の評価を行います。サービス別にSLA評価を実施したり、複数のユーザー部門がある場合にはユーザー部門別にSLA評価を実施したりします。
評価結果は、ユーザーをはじめ第三者に分かりやすい形でレポーティングする必要があります。
図5にSLAレポーティングの1つとしてSLAMチャートを示します。SLAMチャートは、SLA達成状況を日付別、サービスカタログ別に一覧表示したものです。図6にSLAツールによるSLAＭチャートの一例を示します。
SLA Monitoring Chart
＜SLA状況一覧＞
・SLA違反 ■
・警告レベル ■
・SLA達成 ■
＜日付別／サービスカタログ別に表示＞
SLA実現へのコツ
ここまでSLAの概念、SLMプロセス、SLA項目について述べてきましたが、SLA、サービスレベル管理を上手に実現するコツについて述べます。
モニタリングからSLAにつなげる
SLAを実現するためには、ITインフラストラクチャーとしてのシステム状況の正確な把握が必要になります。前回連載した「エンタープライズ・モニタリングのつぼ」では、ITインフラストラクチャーのシステム障害、システム・パフォーマンスの測定技術について解説しましたが、このレベルが実現できている場合、SLAまでは後一歩まで来ています。最初はすでにモニタリングで取得、収集できている測定項目からSLA項目を選択して、始めることをお勧めします。
最初のハードルは低く
最初から高い目標設定や多数のSLA項目の設定、複雑なSLA項目の採用はなるべく避けます。最初に始めるSLA項目は5個程度が適切といわれています。
サービスレベル管理プロセスが回り始めたら、目標値を上方修正したり、徐々にSLA項目を増やしモニタリングの方も追加していきます。
SLA違反に対するペナルティの工夫
SLA成功のコツは、サービス提供側に対する適切なSLA違反に対するペナルティの設定にあります。これは単にペナルティを重くすることではありません。過度なペナルティは、逆効果の場合があります。またSLA開始当初は金銭的なペナルティは、余り望ましくはありません。一時宅配ビザで指定時間内に届かなければ無料という一種のSLA違反のペナルティがありましたが、交通事故を招きかねないという理由で最近は見かけなくなりました。軽いようでも企業、組織に痛みを伴うペナルティ、24時間以内に責任者が改善案を持って謝りに行くなど、創意と工夫を凝らしたものが望まれます。
レポーティングは読まれるものに
SLA項目として取得するデータ量や評価するサービスカタログに比例してレポーティングの量も増加しがちです。膨大なレポーティングは人にすべて読んでもらえない可能性があります。SLAのレポーティングの1つにエグゼクティブ・サマリーと呼ばれるＩＴ責任者向けの要約報告があります。これはSLAの総合評価についてグラフや図を用いて定量的にかつ簡潔に報告するもので、1枚程度にまとめるのが理想とされます。このように、レポーティングは各担当者別に読まれるように作成することが望まれます。
最後に
今回のレポートでは、SLA、サービスレベル管理について概要を説明してきましたが、必要な事項のすべてを説明することはできませんでした。SLA、サービスレベル管理のより詳細な情報に触れたいという方は、ＩＴＩＬ（ Information technology Infrastructure Library）のドキュメントを参照されることをお勧めします。ＩＴＩＬは、英国中央コンピュータ・電気通信局（CCTA：Cental Computer and Telecommunication Agency）によって作成され、その後CCTAは英国商務局（OGC：Office of Government Commerce）に統合された、ＩＴサービス管理における業界のベスト・プラクティスをドキュメント化したものです。ＩＴＩＬでは複数のサービス管理モジュールからなり、サービスレベル管理に関する特定モジュールが含まれています。
Copyright © ITmedia, Inc. All Rights Reserved.