【マンガでわかる】
SLA・SLOの正しい理解で契約トラブル回避

システム運用にかかわる用語の中で、混同されがちなものに「SLA」（Service Level Agreement）と「SLO」（Service Level Objective）がある。この2つの用語の意味、そして両者の違いについて詳しく見ていきたい。

まずSLAを日本語にすると「サービスレベル合意」や「サービスレベル保証」などとなる。サービスの提供者側と利用者側が、そのサービスが満たすべき品質について定量的な指標で合意したものである。

たとえば一般的なクラウドサービスの場合、そのサービスレベルは「可用性」という形で示されることが多い。可用性はサービスが利用できる時間の割合（稼働率）であり、月間の可用性が99％であれば、1カ月30日換算で7.2時間までサービスが停止することを利用者は許容することになる。ちなみにAmazon Web Services（AWS）が提供しているIaaSであるEC2のSLAは月間99.99％であり、月間の停止時間は同じく1カ月30日換算で4.32分となる。

SLAで定義する内容は、サービスの内容によっても異なる。可用性ではなくシステムのパフォーマンスをSLAとして定義することもあり、たとえばシステムにアクセスした際の応答時間や、何らかの検索サービスで検索を行ってから結果が表示されるまでの平均時間をSLAとして定めるといったことが考えられる。

またユーザーからのIT環境に関する問い合わせを受け付けるヘルプデスクであれば、問い合わせを受けてから一次回答を行うまでの時間、あるいは最初の受付で（エスカレーションせずに）回答する割合などをSLAとして設定することが多い。

契約者と利用者が合意するサービスレベルは、定量的に評価できる内容とする必要がある。それは、「業務に支障が生じないようにシステムの稼働率を維持する」などといった曖昧な内容では、合意した内容を客観的に評価できないためである。

このSLAの重要なポイントとして挙げられるのは、合意したサービス基準を満たせなかった場合の罰則を規約に盛り込むことである。前述したEC2であれば、実際の月間稼働率がSLAで定義された稼働率を満たせなかった場合、将来の支払いに利用できるサービスクレジットとして返金するというルールが設けられている。

一方、SLOの日本語訳は「サービスレベル目標」である。こちらはSLAで取り決めた内容を達成するために、サービス提供者側が設定する目標である。一般的にSLOの定義する目標はSLAで設定したものよりも厳しくすることになる。たとえばSLAで月間稼働率99.95％を保証するのであれば、SLOでは月間稼働率を99.99％にするといった具合だ。

SLAとSLOの大きな違いとして、SLOには罰則がないことが挙げられる。そもそもSLOはサービス提供者側の目標値であり、クラウドサービスなどでは利用者側に開示されないことが多い。

なおSLOには、SLAでは設定されない内容が盛り込まれることもある。たとえばメンテナンスを行う際に何日前にサービス利用者に通知するのかといった内容である。

さらに、定性的な内容や具体的な作業手順をSLOとして記載するケースもある。本来であれば運用手順書や作業手順書に記載すべき内容ではあるが、手順の遵守を目標として明確化するためにSLOに記載するというわけだ。

特にパブリッククラウドサービスでは、サービス提供者側がSLAの内容を公開し、利用者はその内容を見て自社の要件を満たすかどうかを判断する形になる。もちろんSLAで定義された内容が必ず満たされると保証されているわけではないが、そのクラウドサービスの品質について判断する基準として利用できるだろう。

自社で構築したシステムの運用をベンダーにアウトソースするなどといった場合には、運用を委託するベンダーとユーザー企業間でSLAを取り決めていくことになる。対象となるシステムの内容や用途からビジネス上必要となる稼働率などを設定し、それを基準にSLAを定めることが一般的だ。

ただ、当然ながらSLAとして設定する項目の達成が難しくなればなるほど、アウトソースのコストは膨らんでいく。稼働率であればベストは100％となるが、一般的なシステムでは現実的な数値とは言えない。コストまで含めて、SLAの妥当性を考える必要がある。

注意したいのは、単にサービスレベルを決めるだけでなく、その計測手法や報告の方法などについても事前に取り決めておくことだ。たとえばSLAの項目として稼働率を採用したのであれば、稼働率をどのように測るのか、測定した稼働率をどのように（運用ベンダーからユーザーに）報告するのかなどといったことも取り決めておきたい。

「SLA」と「SLO」の違い

ここで、SLAとSLOとの違いをもう一度整理しておこう。

SLAは、サービス提供者と利用者が合意する品質水準を明文化したもので、可用性や応答時間、サポート対応時間などを契約上定め、未達時にはペナルティや補償が発生する。一方、SLOは、提供者が内部的に設定する目標値で、SLA より厳しく設定されることが多いが、利用者との契約には含まれず、未達時の罰則は通常ない。また、SLO にはメンテナンス通知や運用手順など定性的な目標を含めることもあり、実務運用を支える役割を果たす。

なおSLAに対する考え方や取り組みはベンダーによって大きく異なるため、ベンダー選定の際にチェックしておく必要がある。NTTドコモビジネスの「X Managed®」では、サービスマネージャがSLAの設定と厳格な運用を支援しているうえ、柔軟なSLAの設定に対応している。また、AWSなどのクラウド上に構築したシステムの運用をアウトソースするのであれば、そのクラウドサービスに精通しているベンダーをパートナーとして選ぶこともポイントとなるだろう。

A：SLAはService Level Agreementの略で、サービス提供者とユーザーの間で、サービスの品質水準について合意するものです。一方、SLOはService Level Objectiveの略で、サービス提供者が設定する具体的な品質目標を指します。例えば、「稼働率99.9％以上」といった数値がSLOにあたります。SLOはSLAの構成要素です。

A：稼働率（可用性）や応答時間（レイテンシ）、エラー率、インシデントの対応時間・解決時間などが代表的な項目です。サービスによっては、複合的なSLOが設定される場合もあります。

A：稼働率や定期メンテナンス時の停止時間・告知方法、障害発生時の対応・報告方法、SLA未達時の補償条件などを確認することが重要です。また、曖昧な表現は解釈の違いによるトラブルの原因になるため、可能な限り具体的な数値で定義しましょう。

A：まず、ユーザーにとって重要な操作や機能を洗い出し、SLOを設定する対象を決めるところから始めます。次に、可用性やレイテンシなど、ユーザー体験への影響を測れる指標を選び、過去の実績データを参考に達成可能な目標値を設定しましょう。必要以上に高いSLOは運用コストの増加につながるため、ユーザーが求める信頼性とのバランスを考慮することが重要です。

A：複数ベンダーがかかわる場合は、各ベンダーのSLAと責任範囲を明確にし、関係者間で認識を統一することが重要です。また、システム全体をエンドツーエンドで監視・可視化し、障害や性能低下が発生した際にボトルネックを特定できる体制を整えましょう。