初めてのサービスレベルアグリーメント【その2】：ITIL Managerの視点から

連載初回では、SLAの意義や作成手順について述べた。今回は、SLAの具体的な中身を解説する。

[谷誠之，ITmedia]

　SLAとは「必ずしもこのような内容が含まれなければならない」というものではない。SLAの前提は、ITがビジネスを適切に支援することを保証することである。そのためにITがどのようなサービスをどの程度提供するのか、というサービスレベルを顧客とサービスプロバイダとの間で合意するわけだ。

　SLAには、次のような内容が含まれる。

1　序文

誰が責任者なのか、誰が当事者なのか、対象となるサービスの範囲はどこなのか、サービス開始日、終了日はいつかのか、といったことを最初になどを明確にする。合意事項に含まれない特別な範囲があれば、ここに明記する。例えばDBの整合性やオリジナルアプリケーションの動作保障などが含まれない場合がある。

2　サービス時間

実際にITがサービスを提供する時間帯を明記する。例えば24時間365日、午前5時から翌日の午前2時、といった具合である。当然、ビジネスに致命的な支障が出てはならない。サービス時間の延長要求に対する取り決めなどもしておく。

3　可用性

顧客の事業活動が行えることを保障する総時間を、通常は単位期間（1年）あたりの割合で表す。上記の例だと、365日のうち稼働時間は1日あたり21時間×365＝7665時間である。もしそのうち24時間は動作しない可能性があれば、可用性は（7665時間−24時間）÷7665時間≒99.69％である。

注意しなければならないのは、可用性とは合意された活動時間の中における動作の割合である。例えば毎晩午前2時〜5時はメンテナンスのために停止する、ということが合意されていれば、その時間内にシステムが（メンテナンス以外の理由で）ダウンしたとしても、可用性は下がったことにならない。

4　信頼性

通常、単位期間（1年）あたりのサービス中断の回数、平均故障間隔（MTBF）などで表す。MTBFや平均修理時間（MTTR）については、追って連載の中で解説する。

5　サポート

サービス時間とサポート時間とが異なる場合、サポート時間を明記する。サポート時間の延長要求に対する取り決めなどもしておく。例えば、延長要求は３営業日前までに申請しなければならない、といったことである。さらに、具体的なサポート手法を明記する。（電話サポート、遠隔管理、物理的な管理など）。また、優先度毎の目標達成時間も取り決めておく。

6　スループット

見込まれるトラフィック量やスループットの指標を明確にしておく。例えばDBサーバの場合は、処理されるトランザクション数、同時ユーザ数、単位時間（秒）あたりのネットワークを流れるデータ量などを想定し、指標を作成する。

7　トランザクション応答時間

DBやネットワークの場合は、１トランザクションあたりの応答時間を平均、または最大の目標時間をコミットする。例えば「2秒以下を95％以上」というように数値化するのが望ましい。

8　変更管理手順

トラブルや負荷増大などの理由でシステムやネットワークなどの構成を変更する場合の決定者、具体的な手順、役割（誰がお金を出すか、誰が作業するか）、実装の目標値（変更が決まってから何日以内に実装するか、実装のためにどの程度システムを止めるか）などを明確にしておく。あらかじめ明確にできない事項がある場合も、「その都度取り決める」ということを明記しておくことが望ましい。

9　ITサービス継続性

致命的なセキュリティ侵害や災害などによってITサービスの継続が困難になった場合の対応策（バックアップ、代替機の準備など）、および責任範疇（例えばDBのバックアップは顧客がとる、など）を明確にしておく。また、ITサービスの継続が不可能になった場合の可用性の修正に関しても言及しおく。

10　課金

サービス時間やサポート時間などを延長する場合、システムやネットワークを増強する場合の課金方法を明らかにしておく。値段が決定できない場合でも、少なくとも「こういう場合は課金しますよ」ということを明らかにしておく。

11　報告およびレビュー

SLAが順守されているかどうかをビジネスと照らし合わせ、SLAが適切かどうかということを定期的に報告、レビューする必要がある。その内容、頻度、報告先、報告方法、ミーティング形態などを決めておき、SLA内で合意しておくことが望ましい。

12　罰則

SLAが順守されなかった場合の責任保証を決めておく。例えば可用性が基準を満たさなかった場合、単位期間（1時間、1日）あたり）○○円を損害金として支払う、といったことを約束しておく。一般的には、顧客がプロバイダに支払った（投資した）金額を超えない範囲で保証することが多い。

---

　これらすべてが含まれる必要はない。初めてSLAを組む場合、いきなりあれもこれも盛り込むと順守することそのものが目的になってしまう可能性もあり、望ましくない。顧客側もプロバイダ側もSLAを組みなれていない場合は、3つから4つ程度の合意事項から始めればいいだろう。そして定期的に（四半期単位や半期単位で）見直していくのである。ただし、有事の責任範囲を明確にするだけのことは、書いておくことが望ましい。

　次回は、SLAの代表的な種類と、SLAを取り巻く追加の合意文書（OLA、UC）などについて述べる。

※本記事の用字用語については、ITILにおいて一般的な表記を一部採用しています。

谷 誠之（たに ともゆき）

IT技術教育、対人能力育成教育のスペシャリストとして約20年に渡り活動中。テクニカルエンジニア（システム管理）、MCSE、ITIL Manager、COBIT Foundation、話しことば協会認定講師、交流分析士1級などの資格や認定を持つ。なおITIL Manager有資格者は国内に約200名のみ。「ITと人材はビジネスの両輪である」が持論。ブログ→谷誠之の「カラスは白いかもしれない」