サービスレベル契約

サービスレベル契約（SLA ）は、サービスプロバイダーと顧客の間の契約です。サービスの特定の側面（品質、可用性、責任）は、サービスプロバイダーとサービスユーザーの間で合意されます。^[1] SLAの最も一般的な要素は、サービスは契約で合意されたとおりに顧客に提供されるべきであるというものです。たとえば、インターネットサービスプロバイダーや通信事業者は、販売されるサービスのレベルをわかりやすい言葉で定義するために、顧客との契約条件にサービスレベル契約を含めるのが一般的です。この場合、SLAには通常、平均故障間隔（MTBF）、平均修復時間または平均回復時間（MTTR）の技術的な定義、障害の報告や料金の支払いの責任の所在の特定、さまざまなデータレート、スループット、ジッター、または同様の測定可能な詳細が含まれます。

サービス レベル契約は、2 つ以上の当事者間の契約であり、1 つは顧客で、もう 1 つはサービス プロバイダーです。これは、法的拘束力のある正式な「契約」または非公式の「契約」(たとえば、内部部門の関係) になります。契約には、別々の組織または 1 つの組織内の異なるチームが関与する場合があります。サービス プロバイダーと他のサード パーティ間の契約は、多くの場合 (誤って) SLA と呼ばれます。サービス レベルは (主要な) 顧客によって設定されているため、サード パーティ間で「合意」することはできません。これらの契約は単なる「契約」です。^{[要出典]ただし、} 運用レベル契約(OLA) は、SLA をサポートするために内部グループによって使用される場合があります。サービスの一部の側面が顧客と合意されていない場合、それは「SLA」ではありません。

SLA には通常、サービスの定義から契約の終了まで、多くの要素が含まれます。^[2] SLA が一貫して満たされるように、これらの契約は特定の境界線で設計されることが多く、関係者は定期的に会合を開いてコミュニケーションの場を設ける必要があります。プロバイダーに適用される報酬と罰則が明記されることがよくあります。ほとんどの SLA では、変更を加えるために定期的に (毎年) 再検討する余地も残されています。^[3]

1980 年代後半から、SLA は固定回線通信事業者によって使用されてきました。SLA は今日では広く使用されているため、大規模な組織では社内に多くの異なる SLA が存在します。組織内の 2 つの異なるユニットが、1 つのユニットが顧客、もう 1 つのユニットがサービス プロバイダーである SLA をスクリプト化します。この方法は、組織内の異なるユニット間、および組織内の複数の場所間で同じサービス品質を維持するのに役立ちます。この内部 SLA スクリプト化は、社内部門と外部サービス プロバイダー間のサービス品質の比較にも役立ちます。^[4]

提供されたサービスの結果として顧客が受け取る出力が、サービス レベル契約の主な焦点となります。

サービス レベル契約もさまざまなレベルで定義されます。

• 顧客ベースの SLA : 個々の顧客グループとの契約で、顧客が使用するすべてのサービスが対象となります。たとえば、財務システム、給与システム、請求システム、調達/購入システムなどのサービスについて、サプライヤー (IT サービス プロバイダー) と大規模組織の財務部門の間で締結される SLA などです。
• サービスベースの SLA : サービス プロバイダーが提供するサービスを利用するすべての顧客に対する契約。例:
  • モバイル サービス プロバイダーは、すべての顧客に日常的なサービスを提供し、ユニバーサル課金によるオファーの一環として特定のメンテナンスを提供します。
  • 組織全体の電子メール システム。提供されるサービスのレベルは顧客ごとに異なる可能性があるため、このタイプの SLA では問題が発生する可能性があります (たとえば、本社のスタッフは高速LAN接続を使用する一方で、ローカル オフィスでは低速の専用回線を使用する必要がある場合があります)。
• マルチレベル SLA : SLA は異なるレベルに分割され、各レベルは同じ SLA 内で同じサービスに対して異なる顧客セットに対応します。
  • 企業レベルの SLA : 組織全体のすべての顧客に該当する一般的なサービス レベル管理(多くの場合、SLM と略される) の問題をすべてカバーします。これらの問題は不安定になる可能性が低いため、更新 (SLA レビュー) が必要になる頻度は低くなります。
  • 顧客レベルの SLA : 使用されているサービスに関係なく、特定の顧客グループに関連するすべての SLM 問題をカバーします。
  • サービス レベル SLA : この特定の顧客グループに関連して、特定のサービスに関連するすべての SLM 問題をカバーします。

明確に定義された典型的なSLAには、以下の要素が含まれます。^[5]

• 提供されるサービスの種類: サービスの種類と、提供されるサービスの種類の追加の詳細を指定します。IP ネットワーク接続の場合、サービスの種類には、ネットワーク機器の運用と保守、提供される接続帯域幅などの機能が記載されます。
• サービスの望ましいパフォーマンス レベル、特に信頼性と応答性: 信頼性の高いサービスとは、特定の時間内に中断が最小限に抑えられ、ほぼ常に利用できるサービスです。応答性のよいサービスは、顧客が要求するとすぐに必要なアクションを実行します。
• 監視プロセスとサービス レベル レポート:このコンポーネントは、パフォーマンス レベルがどのように監視および監視されるかを説明します。このプロセスには、さまざまな種類の統計の収集、これらの統計の収集頻度、および顧客によるアクセス方法が含まれます。
• サービスに関する問題を報告する手順: このコンポーネントでは、問題を報告するための連絡先の詳細と、問題の詳細を報告する順序を指定します。契約には、問題が調査される期間と問題が解決される時期も含まれます。
• 応答および問題解決の期間: 応答期間とは、サービス プロバイダーが問題の調査を開始する期間です。問題解決期間とは、現在のサービスの問題が解決され、修正される期間です。
• サービス プロバイダーが義務を果たさない場合の影響: プロバイダーが SLA に記載されている要件を満たすことができない場合、サービス プロバイダーは結果に直面する必要があります。これらの結果には、顧客が契約を解除する権利や、サービスの失敗により顧客が被った損失の返金を求める権利が含まれる場合があります。

サービス レベル アグリーメントでは、複数のパフォーマンス メトリックを追跡できます。このコンテキストでは、これらのメトリックはサービス レベル インジケーター(SLI) と呼ばれます。特定の SLI の目標値は、サービス レベル目標(SLO)と呼ばれます。

IT サービス管理では、コール センターやサービス デスクが一般的なケースです。このような場合の SLA は通常、次の SLI を指します。

• 放棄率: 応答を待っている間に放棄された通話の割合。対応する SLO は次のようになります: 過去 30 日間のすべての通話の放棄率は 30% 未満である必要があります。
• ASA (平均応答速度): サービス デスクが通話に応答するまでにかかる平均時間 (通常は秒単位)。対応する SLO は次のようになります: 過去 30 日間のすべての通話の ASA は 20 秒未満である必要があります。
• TSF (タイム サービス ファクター): 一定の時間枠内に応答された通話の割合。たとえば、20 秒以内に 80%。対応する SLO は次のようになります: 過去 30 日間の通話の 90% 以上は 20 秒以内に応答する必要があります。
• FCR（初回通話解決率）：コンタクトセンターのエージェントが最初の通話または連絡で顧客の問い合わせや問題を解決する能力を測定する指標。^[6]対応するSLOは次のようになります：過去30日間のすべてのケースのFCRは75％以上である必要があります。
• TAT (ターンアラウンドタイム): 特定のタスクを完了するのにかかる時間。
• TRT (合計解決時間): 特定のタスクを完了するのにかかる合計時間。
• MTTR (平均復旧時間): サービスの停止後に復旧するまでにかかる時間。

稼働時間も一般的な指標であり、共有ホスティング、仮想プライベート サーバー、専用サーバーなどのデータ サービスでよく使用されます。一般的な合意には、ネットワーク稼働時間、電源稼働時間、スケジュールされたメンテナンス ウィンドウの数などの割合が含まれます。

多くの SLA は、IT サービスに適用される場合、 ITIL仕様に準拠します。

インターネットバックボーンサー​​ビスプロバイダー（またはネットワークサービスプロバイダー）が自社のウェブサイトでSLAを明示的に記載することは珍しくありません。^{[7] [8] [9]} 1996年の米国電気通信法は、企業にSLAを持つことを明示的に義務付けてはいませんが、第251条および第252条で企業がSLAを持つための枠組みを提供しています。^[10]たとえば、第252条(c)(1)項（「交渉義務」）では、既存の地域通信事業者（ILEC）に、再販や権利利用などの問題について誠意を持って交渉することを義務付けています。

5Gなどの新しい技術は、ネットワーク事業者に新たな複雑さをもたらします。より厳しいSLAと顧客の期待により、問題解決は影響を受ける加入者に基づいて優先順位を付ける必要があります。^[11]

5G ネットワーク スライシングの導入により、プレミアム SLA を提供し、サービスをより迅速に収益化するために、5G スライスの 360 度ビューを持つことが不可欠になります。

固定ネットワーク加入者にとって、サービスモデリングはSLAを効果的に監視し、SLAが満たされていることを確認するための最も適切な方法の1つであると思われます。^[12]

Webサービス レベル アグリーメント( WSLA ) は、 Web サービスのサービス レベル アグリーメント コンプライアンス監視の標準です。これにより、作成者は、Web サービス アプリケーションに関連付けられたパフォーマンス メトリック、望ましいパフォーマンス目標、およびパフォーマンスが満たされない場合に実行する必要があるアクションを指定できます。

WSLA言語仕様バージョン1.0 ^[13]は2001年にIBMによって公開されました。

クラウド コンピューティングの根本的な利点は、共有リソースです。これは、共有インフラストラクチャ環境の基本的な性質によってサポートされます。したがって、SLA はクラウド全体に広がり、サービス プロバイダーによって顧客ベースの契約ではなくサービス ベースの契約として提供されます。クラウド パフォーマンスの測定、監視、レポートは、エンド UX またはリソース消費能力に基づいています。SLA と比較したクラウド コンピューティングの欠点は、環境の複雑な性質により、サービス中断の根本原因を特定するのが難しいことです。

アプリケーションが専用ハードウェアからクラウドに移行すると、従来のインストールよりもさらに厳しいレベルのサービスを実現する必要があります。クラウドサービスのSLAはデータセンターの特性に重点を置いており、最近ではエンドツーエンドのSLAをサポートするためにネットワークの特性も含まれるようになりました（キャリアクラウドを参照）。^[14]

SLA 管理戦略では、契約の交渉とリアルタイムでの履行の監視という 2 つの明確に区別されたフェーズを考慮します。したがって、SLA 管理には、SLA 契約の定義 ( QoSパラメータを含む基本スキーマ)、SLA 交渉、SLA 監視、SLA 違反の検出、および定義されたポリシーに従った SLA の適用が含まれます。^{[引用が必要]}

主なポイントは、グリッド、クラウド、またはSOAミドルウェア上に、サービス提供者とサービス消費者間の交渉メカニズムを作成できる新しいレイヤーを構築することです。一例として、EU が資金提供している Framework 7 研究プロジェクト SLA@SOI ^{[15]では、サービス指向インフラストラクチャとクラウド コンピューティング内のマルチレベル、マルチプロバイダー SLA の側面を研究しています。また、EU が資金提供している別のプロジェクト VISION Cloud [16]}では、コンテンツ指向の SLA に関する結果を提供しています。

FP7 IRMOSは、クライアント側の期待とクラウドプロバイダーのリソース管理メカニズムの間のギャップを埋めるために、アプリケーションレベルのSLA用語をリソースベースの属性に変換する側面も調査しました。^{[17] [18]} SLAの分野におけるさまざまな研究プロジェクトの結果の概要（仕様から監視、管理、施行まで）は、欧州委員会によって提供されています。^[19]

アウトソーシングでは、組織からサプライヤーに責任が移管されます。この新しい取り決めは、1 つ以上の SLA を含む契約を通じて管理されます。契約には、SLA メトリックのいずれかが継続的に満たされなかった場合の金銭的ペナルティや契約解除権が含まれる場合があります。SLA の設定、追跡、管理は、アウトソーシング リレーションシップ管理(ORM) の重要な部分です。特定の SLA は通常、アウトソーシング契約の一部として事前に交渉され、アウトソーシング ガバナンスの主要なツールの 1 つとして使用されます。

ソフトウェア開発では、ソフトウェア品質の標準に沿った特定のSLAをアプリケーションアウトソーシング契約に適用できるほか、CISQなどの中立的な組織が提供する推奨事項も適用できます。CISQはこのトピックに関する多数の論文（ SLAでのソフトウェア測定の使用^[20]など）を公開しています。

• ベストエフォート配信
• ITコストの透明性
• ネットワーク監視
• 運用レベル契約(OLA)
• サービスレベル
• サービスレベル目標
• サービス指向アーキテクチャ(SOA)

• サービス レベル アグリーメント (SLA) S-Cube 知識モデル