SLI, SLO, SLAの違いと活用を理解する

SLI（サービスレベル指標）とは？

定義

SLI（Service Level Indicator）とは、サービスの健全性やパフォーマンスを定量的に測定する指標のこと。ユーザー体験に直結する観点で、システムの状態を数値で表す。

• SLI = 測定するメトリクス
• SLO = そのメトリクスに対する目標値
• SLA = SLOが守られなかった場合の契約内容

目的

• サービスの品質を客観的に評価するための基盤。
• SLOやSLAの達成度を判断するために使用される。
• 信頼性エンジニアリング（SRE）において、リアルタイムのシグナルとして活用される。

例

カテゴリ	SLIの例
可用性	成功したリクエストの割合（例：99.95%）
レイテンシ	95%のリクエストが100ms以内で処理された
スループット	1秒あたりに処理されるリクエスト数
エラー率	全リクエストのうち失敗した割合（例：0.1%）
サチュレーション	CPUやRAMの使用率（例：70%未満）
キャッシュ率	キャッシュされた応答の割合
データ鮮度	データの更新から読み取りまでの時間

ポイント

• 「何を測るか」がSLI。
• SLIは最も柔軟性が高い指標であり、技術の進化に応じて更新可能。
• 適切なSLIの選定は、ユーザー体験とビジネス目標の両方を理解することが鍵。

SLIの選定と測定のベストプラクティス

1. ユーザーにとって重要な体験を中心に指標を選定。
2. 監視・ログシステムを活用して正確なデータを収集。
3. 定期的な検証と調整により、測定精度と妥当性を維持。
4. メトリクスの絞り込み：多すぎる指標は混乱を招くため、目的に応じて厳選。

SLO（サービスレベル目標）とは？

定義

SLO（Service Level Objective）とは、サービスの品質に関する具体的な目標値を指す。これは、SLI（Service Level Indicator：サービスレベル指標）で測定された値に対して、どの程度の水準を維持すべきかを定めるものである。

• SLI = 測定値
• SLO = その測定値に対する目標
• SLA = SLOが守られなかった場合の契約・救済措置

目的

• チームや組織が「どの程度の品質を保証するか」を合意するための基準。
• 顧客満足度や信頼性の向上を目指し、技術的な指標とビジネス目標を橋渡しする役割を果たす。

例（New Relicの事例も含む）

カテゴリ	SLOの例
可用性	30日間のアップタイムは99.9%
レイテンシ	95%のリクエストは2秒以内に処理
エラー率	全リクエストのうち0.1%未満が失敗
スループット	ピーク時に1秒あたり10,000件のリクエスト処理
使用率	RAM使用率は常に70%未満
耐久性	1年間で99.9999999%のデータ耐久性
導入率	98%の変更をロールバックなしで実施

ポイント

• 「どこまで守るか」がSLOの本質。
• SLOは柔軟性が高く、技術的・ビジネス的な要件に応じて更新可能。
• SLOが厳しすぎると俊敏性や革新性を損なう可能性があるため、達成可能かつ挑戦的なバランスが重要。

設定のベストプラクティス

1. ユーザーの期待とニーズを理解する。
2. システムの履歴データを分析し、現実的な目標を設定。
3. チーム全体で合意し、定期的に見直す。
4. エラーバジェットを活用して、SLO違反の許容範囲を管理。

SLIとSLOの関係性

基本構造

用語	意味	役割
SLI	Service Level Indicator（サービスレベル指標）	実際のサービス品質を数値で測定する「現実」
SLO	Service Level Objective（サービスレベル目標）	SLIに対して設定する「目標値」

• SLI = 測定値
• SLO = 測定値に対する目標

関係性のイメージ

SLOは、SLIという「実測値」に対して「どこまで守るか」を定める理想像である。
SLIは、SLOが達成されたかどうかを判断するための根拠データである。

具体例

指標	SLI（測定値）	SLO（目標値）	判定
可用性	今月のリクエスト成功率 = 99.92%	「99.9%以上を維持する」	○ 達成
レイテンシ	95%のリクエストが120ms以内	「95%が100ms以内」	× 未達成
エラー率	0.08%のリクエストが失敗	「0.1%以下」	○ 達成

ポイント

• SLIは客観的な測定値であり、SLOは主観的な目標値。
• SLOはSLIをもとに設定され、SLIはSLOの達成度を評価するために使われる。
• SLOが達成されていない場合、エラーバジェットの消費や改善アクションが必要になる。

実務での使い方

• SREチームはまずSLIを定義し、そこからSLOを設定。
• SLOの達成状況をSLIでモニタリングし、必要に応じてアラートや改善策を実施。
• SLA（契約）では、SLOとSLIの両方が記載され、達成されなかった場合の対応が定義される。

SLA（サービスレベル契約）とは？

定義

SLA（Service Level Agreement）とは、サービス提供者と顧客の間で交わされる契約であり、サービスの品質に関する期待値と、それが守られなかった場合の対応（返金・クレジットなど）を明記したもの。

• 法的拘束力を持つ文書であり、ビジネス・法務・技術の関係者が関与して作成される。
• SLO（目標）とSLI（測定値）を含み、それらに基づいてサービスの品質を保証する。

目的

• 顧客に対してサービスの品質を明確に提示する。
• サービス提供者の責任範囲と対応義務を定義する。
• 信頼性・透明性・安心感を提供する。

例

指標	SLO（目標）	SLA（契約）
可用性	99.9%以上	99.0%を下回った場合は返金
レイテンシ	95%のリクエストが100ms以内	90%未満の場合はクレジット提供
エラー率	0.1%以下	0.5%以上で契約違反とみなす

ポイント

• SLI：実際の測定値（例：今月の成功率99.92%）
• SLO：目標値（例：99.9%以上）
• SLA：SLOが守られなかった場合の契約（例：99.0%未満なら返金）

SLAの構成要素

• サービスの範囲と対象
• 測定方法（SLI）
• 目標値（SLO）
• 例外事項（自然災害など）
• 責任分担（顧客と提供者）
• 可用性と対応時間
• ペナルティや救済措置（クレジット、返金など）

---

まとめイメージ

用語	役割	例え
SLI	測定値	「今の成績」
SLO	目標値	「合格ライン」
SLA	契約	「合格ラインを守れなかったらどうするか」

一般的なベストプラクティスとして、SLI → SLO → SLA の順番で設定するのが推奨されているように解釈した。参考：SLA、SLO、SLI：サービスレベルを理解する

これは、技術的な測定から始まり、目標設定、そして契約へと段階的に進むことで、現実に即した信頼性管理が可能になるからだと思われる。

---

設定の順番と理由

1. SLI（測定値）から始める

• 実際のシステムのパフォーマンスやユーザー体験を数値で把握。
• 例：APIの応答時間、エラー率、成功率など。
• 理由：現実のデータがなければ、目標も契約も空論になる。

2. SLO（目標値）を設定する

• SLIをもとに、どの水準を維持すべきかをチームで合意。
• 例：95%のリクエストは300ms以内に処理する。
• 理由：達成可能かつ挑戦的な目標を設定することで、信頼性と俊敏性のバランスが取れる。

3. SLA（契約）を定義する

• SLOをベースに、顧客との契約内容を明文化。
• 例：99.0%を下回った場合は返金。
• 理由：法的拘束力を持たせることで、顧客との信頼関係を構築。

---

SLAから策定するような場面では、この順番でなければならないという訳ではなさそう。
SLAがなく、SLI/SLOのみを設定する場面もあるのではないかと想像した。

エラーバジェットとは？

エラーバジェット（Error Budget） とは、SLO（サービスレベル目標）を達成するために、許容される失敗の余地を数値化したもの。

例：

• SLOが「99.9%の稼働率」である場合、残りの 0.1%（約43分/月） が「エラーバジェット」となる。
• この時間内であれば、障害やパフォーマンス低下が発生しても「許容範囲」とみなされる。

---

エラーバジェットの活用方法

以下のように、開発と運用のバランスを取るための戦略的なツールとして使われる。

活用方法	内容
リリース判断	エラーバジェットが残っていれば、新機能のリリースを進める。使い切っていれば、リリースを停止して信頼性改善に集中。
チーム間の調整	開発チーム（新機能重視）と運用チーム（安定性重視）の対立を防ぎ、共通の信頼性目標を持たせる。
インシデント対応の優先度判断	エラーバジェットの消費量に応じて、どのインシデントを優先して対応すべきかを判断。
SLOの見直し	エラーバジェットが頻繁に使い切られる場合、SLOが厳しすぎる可能性があるため、再設定の検討材料になる。

---

参考リンク

• New Relic公式：SLO、SLI、SLAの違いとエラーバジェットの活用
• Qiita：SREとエラーバジェットの関係