今日のサービス中心の世界では、企業は卓越したユーザーエクスペリエンスを提供する必要があります。サービス品質の向上は、顧客の長期的な維持と顧客ベースの拡大につながります。そこで、優れたサービスを提供するために効果的なのが、サービスのパフォーマンスと、いくつかの重要なメトリクスやシグナルを監視することです。
サービスレベル契約(SLA)、サービスレベル目標(SLO)、サービスレベル指標(SLI)はいずれも、組織が製品やサービスのパフォーマンスと品質を保証し、その目標の達成状況を監視するための指標です。
このブログ記事では、SLA、SLO、SLIの違いと、これらの指標を組織に導入するうえでの課題およびベストプラクティスについて説明します。
Splunk IT Service Intelligence (ITSI)は、顧客に影響が及ぶ前にインシデントを予測して対応するための、AIOps、分析、IT管理ソリューションです。
AIと機械学習を活用して、監視対象のさまざまなソースから収集したデータを相関付け、関連するITサービスやビジネスサービスの状況を1つの画面にリアルタイムで表示します。これにより、アラートのノイズを低減し、障害を未然に防ぐことができます。
サービスレベル契約(SLA)は、サービスの提供者と利用者の間で結ぶ契約です。利用者に影響する問題の解決時間、サービスの稼動時間、Webサービスの応答性など、サービスに関する具体的な責任について取り決めます。どのSLAも利用者への「保証」である点は同じですが、実際の内容はさまざまです。
SLAの内容は、業種やサービス提供者によって大きく異なります。組織が提供する有料サービスのSLAを作成するのは、通常、事業部門か法務部門です。これらのSLAには以下の主要項目が含まれます。
SLAを作成するのは組織の事業部門や法務部門ですが、技術的な制約を見落とさないために、技術部門に協力を求めることが重要です。
サービスレベル目標(SLO)は、特定の測定値について利用者に提示するサービスレベルの目標を指します。測定値には以下のようなメトリクスが使われます。
SLAとは異なり、SLOでは、保証の対象となる各測定値について具体的な目標値を定義します。SLAは、サービス提供者がサービスのパフォーマンスや品質について保証する正式な契約です。一方、SLOは、SLAの達成状況を評価するためにサービス提供者が内部で設定する明示的な目標です。
例として、アマゾン ウェブ サービス(AWS)社が個々のEC2インスタンスについて設定しているSLOの一部を以下に示します。
サービスレベル指標(SLI)は、サービスのパフォーマンスを測定するための主な指標を指します。定義したSLOの達成状況を評価するための基準として利用できます。
SLAが定義であるのに対して、SLIは実測値または履歴の値を示します。これらの値が、定義したSLOを下回った場合は、サービスに問題があると判断します。その場合は、SLOを達成できるようにサービスを最適化するか、SLOを現実的なレベルに調整します。
たとえば、前述のAWS EC2の例では、SLOが99.0%以上、99.5%未満なので、SLIでのサービス稼動率の実測値は99.26%あたりでしょう。
次の表に、SLA、SLO、SLIの主な違いを示します。
SLA | SLO | SLI | |
目的 | サービスに対する責任について利用者と同意する | 利用者に対するサービス目標の達成状況を組織内で評価するためにパフォーマンス測定の基準を設定する | SLOの実測値を記録してサービスのパフォーマンスを測定する |
適用対象 | 有料サービス | 無料サービスと有料サービスの両方 | パフォーマンス測定にSLOを定義した場合に必須 |
設定項目 | 範囲、指標、法的および財務的な影響 | SLAを達成するための具体的な目標 | パフォーマンスを評価するための実測データ |
例 | 稼動率、可用性、問題の解決時間 | 応答時間300ミリ秒以内、エラー率2%未満 | 平均応答時間 = 250.1ミリ秒 稼動率 = 98.9% |
柔軟性 | 変更が必要な場合は、サービス提供者、法務部門、サービス利用者の間で合意が必要なため、柔軟性が低い | SLAよりも柔軟性が高く、技術的な要件やサービス要件に応じて更新可能 | SLOよりも柔軟性が高く、パフォーマンス要件の変更に合わせて調整可能 |
これらの「指標」はいずれも多種多様なビジネスやサービスに適用できますが、特に一般的に使われるのがサイトリライアビリティエンジニアリング(SRE)の領域でしょう。SREで成果を達成するには可用性の確保が不可欠なため、システムパフォーマンスの継続的な信頼性を定量化したいSREにとってSLA、SLO、SLIは重要な手段です。
目的が何であれ、組織においてこれらの指標を効果的に測定し適用するには、いくつかの課題があります。
SLA、SLO、SLIを導入するうえで直面しがちな課題についてそれぞれ見ていきます。
技術部門の協力がないと非現実的なSLAが作成される恐れがある
SLAを作成、定義するのは組織の法務部門や事業部門ですが、これらの部門には通常、サービスの技術面に関する十分な知識がありません。その結果、非現実的なSLOが設定され、達成が難しくなる可能性があります。
たとえば、法務部門が可用性の目標を99.999%に設定したとします。法務部門にとって「可用性が高い」といえばこのくらいの値だからです。しかし、ソフトウェア、ハードウェア、ネットワークの障害や、サードパーティサービスとの依存関係など、目標達成の阻害要因を考慮した値とは言えません。
利用者のニーズや技術の進化に合わせてSLAを最新の状態に保つ必要がある
技術は急速に進化していますが、サービス提供者のリソースや予算の都合によって、こうした急激な変化に追いつくのが難しい場合もあるでしょう。同様に、顧客のニーズも絶えず変化しており、継続的な調整と再交渉が必要になります。
コストがかかる
定義したSLAを維持するには、人的リソースと最新テクノロジーへの投資が不可欠です。そうなれば当然、コストが増加します。
難易度のバランスを取るのが難しい
測定があまりにも難しいSLOを設定してしまうことがあります。最初に目標を明確に定義しないと、その達成方法を決めるために時間を無駄にすることになります。逆に、達成が容易なSLOを設定してしまうと、利用者の期待に応えられない可能性があります。バランスの取れたSLOを設定するには熟慮が必要です。
適切なメトリクスを選択する必要がある
組織のビジネス目標や利用者の期待に沿わないメトリクスを選択してしまうと、SLOが、利用者に保証した内容と食い違うことになります。
利用する外部サービスを管理できない
サービスの中でサードパーティのコンポーネントやサービスを利用することはよくあります。これらの外部サービスで障害が発生すると、組織内のコンポーネントに異常がなくても、サービスのSLO達成に影響が及ぶ可能性があります。
メトリクスが多すぎる
メトリクスが多すぎると、測定が複雑になるわりに、利用者にとってはたいした違いがないことがよくあります。
一部のメトリクスは測定が難しい
正確に測定するのが難しいパフォーマンスメトリクスもあります。たとえば、ユーザーエンゲージメント、リアルタイムアプリケーションの遅延、ユーザーの全体的な満足度は通常、測定が困難です。
値を正確に測定するのが難しい
SLOの各パフォーマンスメトリクスを正確に測定することは重要です。そのためには、テストと監視段階で正確性と信頼性を確保する必要があります。
課題があっても、サービスや製品を提供する組織にとってSLA、SLO、SLIはどれも導入する価値が十二分にあります。これらの指標を最大限に活用するためのベストプラクティスをご紹介します。
要約すると、SLAはサービス提供者と利用者の間で合意する全体的な契約、SLOは利用者に保証する具体的な目標、SLIはパフォーマンスを測定するための実際の値を指します。
ビジネスやITに関する多くの課題と同様に、SLA、SLO、SLIに関する一般的な課題も、ベストプラクティスに従えばたいていは克服できます。これらの指標を有効活用すれば、サービスの信頼性と有用性を最大限に向上させることが可能です。
このブログはこちらの英語ブログの翻訳です。
この記事について誤りがある場合やご提案がございましたら、ssg-blogs@splunk.comまでメールでお知らせください。
この記事は必ずしもSplunkの姿勢、戦略、見解を代弁するものではなく、いただいたご連絡に必ず返信をさせていただくものではございません。
Splunkプラットフォームは、データを行動へとつなげる際に立ちはだかる障壁を取り除いて、オブザーバビリティチーム、IT運用チーム、セキュリティチームの能力を引き出し、組織のセキュリティ、レジリエンス(回復力)、イノベーションを強化します。
Splunkは、2003年に設立され、世界の21の地域で事業を展開し、7,500人以上の従業員が働くグローバル企業です。取得した特許数は1,020を超え、あらゆる環境間でデータを共有できるオープンで拡張性の高いプラットフォームを提供しています。Splunkプラットフォームを使用すれば、組織内のすべてのサービス間通信やビジネスプロセスをエンドツーエンドで可視化し、コンテキストに基づいて状況を把握できます。Splunkなら、強力なデータ基盤の構築が可能です。