SLA、SLO、SLI の比較: 相違点は何か?

SLA とは?

SLA (サービス レベル アグリーメント) は、アップタイム、応答性、責任などの測定可能な指標に関する、プロバイダーとクライアント間の契約です。

これらの契約は通常、会社の新しいビジネス チームや法務チームによって作成されていて、お客様に対する約束とその約束を守れなかった場合の結果を表します。通常、この結果には、違約金、サービス クレジット、ライセンス延長が含まれます。

SLA の課題

SLA は、測定、報告、適合が困難であることがよく知られています。これらの契約は、一般的に技術畑出身ではない人々によって作成されているため、多くの場合、チームにとって測定が困難な約束が定められています。現在の進化し続けるビジネスの優先事項と必ずしも一致しているとは限らず、微妙な違いも考慮されていません。

たとえば、SLA では、製品 X について報告された課題をチームが 24 時間以内に解決することを約束しているとします。しかしこの SLA では、チームが課題を診断するのに役立つ回答やスクリーンショットをクライアントが送信するのに 24 時間かかった場合はどうなるかということについて明記されていません。この場合、チームに与えられた 24 時間の時間枠はクライアントの遅延によって消費されてしまうのか、あるいはクライアントの応答タイミングに基づいて時間枠を開始、終了するのでしょうか? SLA ではこれらの質問に答える必要がありますが、多くの場合、答えが示されていません。その結果、実際に IT マネージャーが SLA に対して強い反感を抱いています。

多くのパートナーにとってこの課題に対する答えは、第一に SLA の作成には技術者が関与すべきであるということです。現実のシナリオに対応する SLA を策定するために IT と DevOps が法務および事業開発部門とのコラボレーションを強化するほど、クライアントによる自社の課題解決の遅延など、重要な現実を SLA に反映できるようになります。

SLA を必要とするユーザー

SLA は、ベンダーと対価を支払うお客様との間の契約です。ユーザーに無料でサービスを提供している企業がそれらの無料ユーザーのために SLA を求めたり必要としたりすることは、めったにありません。

SLO とは?

SLO (サービス レベル目標) とは、アップタイムや応答時間などの特定の指標に関する SLA 内の合意です。したがって、SLA がお客様とお客様の顧客との間の正式な合意であれば、SLO はお客様から当該顧客に対する個々の約束です。SLO は、顧客の期待値を設定して、IT チームと DevOps チームが達成および測定する必要がある目標をチーム メンバーに伝えるためのものです。

SLO の課題

SLO は SLA ほどの反感は持たれませんが、曖昧であったり過度に複雑であったり測定不可能であったりすると、それに応じて多くの問題が発生する可能性があります。エンジニアの不満をかきたてることのない SLO を設定する鍵は、シンプルさと明快さです。最も重要な指標のみを SLO ステータスの対象とし、目標を分かりやすい言葉で記述し、SLA の場合と同様にクライアント側の遅延などの課題を必ず明確にする必要があります。

SLO を必要とするユーザー

対価を支払うお客様にのみ SLA が該当する場合、SLO は有料および無料アカウントの両方、および社内外の顧客にも役立ちます。

CRM、クライアント データ リポジトリ、イントラネットなどの社内システムは、社外向けシステムと同様に重要な場合があります。また、これらの社内システム用として SLO を設定することは、ビジネスの目標を達成するだけでなく、社内チームが顧客向けの独自の目標を達成できるようにする上で重要な要素です。

SLI とは?

SLI (サービス レベル指標) は、SLO (サービス レベル目標) へのコンプライアンスを測定します。このため、たとえば、システムが契約時間のうち 99.95% 利用可能であると SLA に規定されている場合、SLO は 99.95% のアップタイムとなり、SLI はアップタイムの実際の指標となります。これは 99.96% である場合も、99.99% である場合もあります。SLA のコンプライアンスを維持するには、SLI がその文書で定められた約束を満たすか、それを超える必要があります。

SLI の課題

SLO と同様に、SLI の課題は、SLI をシンプルに保ち、追跡するために適切な指標を選択すること、そしてクライアントにとって実際には重要でない指標を多数追跡して IT の業務を必要以上に複雑にしないようにすることです。

詳細なディザスタ リカバリ計画の作成

ダウンタイムが発生した場合にどうするか? この質問に対する答えがまだわからない場合、一般的な答えは「実行すべきことを考え出すために貴重な時間を無駄にする」です。

インシデント対応計画が改善されるほど、チームがより迅速かつ効果的にインシデントを処理できるようになります。このため、新しいインシデント管理プログラムの最初のステップはプロセスと計画である必要があります。

SLI を必要とするユーザー

SLO に基づいてパフォーマンスを測定する企業は、これらの測定を行うために SLI を必要とします。SLI がなければ実際に SLO は設定できません。

顧客の期待に沿った SLA の作成

カスタマー契約のすべての部分は、顧客にとって重要なことを考慮して作成する必要があります。バック エンドでは、1 つのインシデントによって 10 個の異なるコンポーネントに対処することを意味する場合があります。しかし、クライアント側から見れば、システムが期待どおりに機能することが最も重要です。

SLA と SLO には、この事実を反映する必要があります。細かいレベルまで掘り下げて、これら 10 個のコンポーネントのそれぞれについて個々の約束を定め、物事を過度に複雑にしないようにしましょう。約束の対象は、俯瞰的なユーザー向け機能に限定します。これにより、クライアントの満足度が維持されて混乱が減り、SLA の約束を履行する責任を負う IT 専門家の業務がシンプルになります。

SLA では分かりやすい言葉を使用する

クライアントからは必ずしも細かい説明を求められるわけではないため、SLA の言葉が複雑な場合、将来的に厄介な誤解が生じる恐れがあります。言葉がシンプルになればなるほど、将来的にクライアントと衝突する可能性が低くなります。

SLO が少ないほど効果が上がる

すべての指標がクライアントの成功に不可欠なわけではありません。つまり、すべての指標を SLO にする必要はありません。できる限り SLO の項目を減らすように取り組んで、顧客にとって最も重要なものに焦点を当てます。

追跡可能な指標すべてを SLI に設定しない

同様に、10 個の SLO ごとに 10 個のコンポーネントのパフォーマンスを追跡すると、あっという間に扱いづらくなります。代わりに、主要な SLO に実際に重要である指標を戦略的に選択して、それらを効果的に追跡することに注力します。

IT チームの制御の範囲外にある要素を含める

解決までの時間を遅くしている原因がクライアントである場合は、どうなるでしょうか? SLA でこの内容を明確にしないと、クライアントが関与することなくクライアントの課題を解決するという、あり得ない基準にチームが縛られてしまう可能性があります。

エラー予算を確保する

障害に備える余地を残すことで、SLA 違反や重大な結果からビジネスを保護するだけでなく、アジャイルへの余地も残せます。これにより、チームは迅速に変更を行い、失敗する可能性はあるが革新的な新しいソリューションを試す余地を確保できます。

Google では実際に、残ったエラー予算を計画的なダウンタイムのために使用することを推奨しています。これにより、予期せぬ課題 (サーバーを不適切に使用したサービスなど) を特定し、クライアントからの期待を適切に維持できるようになります。

困難にあえて挑戦しない

チームがほぼ確実に 99.99% のアップタイムを維持できるからといって、SLO の数値を 99.99% にすべきではありません。約束は控えめにして結果を期待以上にするほうが常にうまくいきます。特にこれは、早期かつ頻繁にリリースすることを希望して、迅速なペースを維持するためにエラー予算を必要とするアジャイル チームに当てはまります。

SRE に与える影響

Google のモデルに従い、Site Reliability Engineering (SRE) チームを利用して開発と運用のギャップを埋めている場合、SLA、SLO、SLI は成功の基盤となります。SLA は、チームが境界とエラー予算を設定するのに役立ちます。SLO は、作業の優先順位付けに役立ちます。また SLI は、尽きかけているエラー予算を節約するためにすべてのリリースを凍結する必要があるタイミング、およびその抑制を緩和できるタイミングを SRE に伝えます。

Jira Service Management によって、SLA を常に把握して優先度に応じてリクエストを解決し、自動化されたエスカレーション ルールを使用して適切なチーム メンバーに通知し、SLA 違反を防止しましょう。