SLOとは？サービス信頼性目標を実装する方法
要約
SLOはサービス信頼性を測定・管理するための目標値。SLIは生の測定値、SLAは顧客契約。エラー予算は意思決定ツール。実装には過去データ分析、ウィンドウ設定、ポリシー文書化が必須。四半期ごとのレビューで継続改善する。
SLOとは？サービス信頼性目標を実装する方法
SLOとは何か。SLO（Service Level Objective、サービスレベルオブジェクティブ）はチームが自分たちに課すサービス信頼性目標です。これは顧客との契約ではなく、監視ツールから出てくる生のメトリクスでもありません。SLOが答える質問は実はとてもシンプルで1つだけです。「このサービスはどの程度の信頼性が必要か、そしてそれをどのように測定するか」という質問です。
完全なSLOはこのようなかたちになります。「/api/checkoutへのHTTPリクエストの99.9%が成功ステータスを返し、300ミリ秒以内に完了すること。ローリング30日期間で測定される」という具合です。ここで重要なのは、測定、目標、測定期間という3つの要素があること。この3つすべてが信頼性スコアの精度に直接影響します。
SLI、SLO、SLA：似ているようで異なる3つの用語
実務ではSLI、SLO、SLAという3つの用語が常に一緒に出現します。多くのチームがこれらの用語を同じ意味で使っていることもありますが、実は異なるものを指しています。正確な理解が重要です。
**SLI（Service Level Indicator、サービスレベルインジケータ）**は監視システムが生成する生の測定値です。これは総リクエスト数に対するエラー率の割合、ミリ秒単位のP99レイテンシ、データベースへの成功した書き込みの割合など、様々な形をとります。SLIはDatadog、Grafana、またはそれ以外の監視ツールから出てくる数値です。つまりSLIは「何が起きたか」を教えてくれるシグナルです。
**SLO（Service Level Objective、サービスレベルオブジェクティブ）**はSLIの上に定義した目標値です。これは「このSLIが取りうるすべての値のうち、どの範囲が許容できるのか」という問いに答えます。例えば、SLIがエラー率で、SLOが「5分間のウィンドウの99%でエラー率が0.1%以下」なら、ダッシュボードの単なる数値ではなく、合格/不合格のテストを持つことになります。
**SLA（Service Level Agreement、サービスレベルアグリーメント）**はこれと同じロジックの外部版で、重要な違いは契約上の影響があるということです。SLAは「99.5%のアップタイムがない場合、20%のサービスクレジットを発行する」と言うかもしれません。チームはSLOをそのしきい値より上に設定すべきです。そうすることで、顧客との問題になる前に、劣化についてチーム内で知ることができるようになります。
SLOとSLAの間のギャップは不注意のためのパッディングではなく、意図的に設計された余裕です。この余裕がチームに「違反に向かっている」という警告を「今すぐ修正する時間がある」という実行可能な情報に変えます。これが信頼性文化の基本です。
もう1つの重要な区別があります。SLIは継続的に測定されますが、SLOはウィンドウにわたって評価されるという点です。7日間対30日間で測定した同じエラー率は、非常に異なる合格/不合格結果を生成します。1つの悪い時間は7日のウィンドウではかなり重要ですが、30日のウィンドウではおよそ1%に過ぎません。正しいウィンドウを選ぶことは、正しい目標を選ぶのと同じくらい重要な決定です。
「どの程度の信頼性？」という質問だけでは不十分な理由
数値を選ぶ前に、サービスが劣化したときにユーザーが実際に何を経験するかを理解する必要があります。「5つのナイン（99.999%）が必要」というのは野心の表明であり、測定ではないからです。チェックアウトAPIが99.999%の可用性で稼働することは、月あたり約26秒のエラー時間を意味します。1秒あたり10トランザクションを処理するサービスではおそらく許容されますが、リアルタイム金融決済を処理するサービスではそうではないかもしれません。
適切なSLOを決定する際に考慮すべき2つの要因があります。1つはサービスの劣化がユーザーに及ぼす影響、もう1つはより厳しい目標を維持するための運用コストです。
サービスの可用性が過去90日間で99.3%を記録している場合、最初のSLOを99.9%で開始することは野心的ですが、キャリブレーションされていません。実践的で現実的なアプローチはこのようなものです。過去90日のSLIデータを取得し、SLOを現在のパフォーマンスより少し厳しく設定し、その後3ヶ月ごとに見直す。99.5% SLOと厳格に実装されたエラー予算ポリシーの組み合わせは、99.9% SLOを毎回違反してから無視するより優れています。
サービスタイプ別の一般的なSLO目標を以下に示します。
ユーザー向けAPI（チェックアウト、認証）：99.9%の可用性、P99レイテンシ500ミリ秒以下が推奨
内部サービス（データパイプライン、バッチジョブ）：99.5%の成功率で測定、ジョブ完了時に評価
管理ツール：99%の可用性で十分なことが多い
バックグラウンドワーカー：HTTPステータスではなく、ジョブ完了時間でSLOを設定
測定するSLIを選ぶときは、Googleの「SRE Book」に記載されている4つの信号を出発点として使用してください。可用性（リクエストは成功したか）、レイテンシ（どのくらい時間がかかったか）、スループット（システムはいくつのリクエストを処理しているか）、エラー率（どのくらい失敗したか）です。すべてのサービスが4つも必要ではありません。ほとんどのチームが得られる信頼できるシグナルは可用性とレイテンシパーセンタイルの1つからです。最初の2つに対して確実なベースラインを持つ前により多くのSLIを追加することは、洞察を得ずにノイズを生成する一般的な落とし穴です。
エラー予算：信頼性目標から実際の運用判断へ
エラー予算は数学的にはSLOの逆数です。可用性SLOが99.9%の場合、測定ウィンドウ内のリクエストの0.1%が失敗することを許可されます。月に100万リクエストを受け取るサービスの場合、SLOが違反される前に1,000の失敗したリクエストが計画的に許可されます。
エラー予算がSLOを実装する際に重要な理由は、それがSLOを運用的に有用なツールに変えるからです。エラー予算なしでは、SLOは単なるしきい値で、それを超えると議論が始まります。エラー予算ポリシーを使えば、これは意思決定フレームワークになります。
エラー予算が健全な状態、例えば2週間残して80%の余裕がある場合、チームは高速に配船できます。新しい機能のリリース、実験、リスクの高い配置はすべてが可能です。エラー予算は「速度は現在制約ではない」というシグナルを送っています。
逆にエラー予算が減少している場合、チームはシフトします。重大でない変更は保留されます。配置ポリシーはより厳しくなります。信頼性の修正は最優先されます。この判断はマネージャーの裁量ではなく、エラー予算というデータが判断を下しています。
具体的なシナリオを紹介します。チェックアウトサービスが火曜日の午後に12分間の劣化を経験し、月次エラー予算の15%を消費しました。木曜日の別のインシデントは12%をさらに消費しました。月の最初の週で27%消費されている時点で、エラー予算ポリシーが自動的に発動します。根本原因が修正され、ポストモーテムが完了するまで、新しい機能の配置は禁止されます。これは製品チームとエンジニアリングチームの交渉ではなく、データの直接的な読み取りです。
Googleはその「SRE Workbook」で信頼できるエラー予算ポリシーを公開しました。その中の1つが「単一のインシデントが四半期エラー予算の20%以上を消費する場合、必ずポストモーテムを実施する」というものです。これはチームが採用・適応できる具体的で実用的なポリシーです。
バーンレートアラートはこれをさらに一歩進めます。エラー予算がほぼ消費されるまで待つ代わりに、バーンレートアラートは消費率がウィンドウの終了前に予算を使い尽くすことを示唆するときに発火します。例えば、サービスが通常のレートの14倍でエラー予算を消費している場合、30日の予算を約50時間で使い尽くすでしょう。このレートでのアラートは、違反が発生した後にポストモーテム通知を受けるのではなく、対応に2日間の時間をチームに与えます。DatadogとGrafanaはボックスのアウトで多重ウィンドウの複数バーンレートアラートをサポートしています。セットアップには通常1日程度かかります。これがなければ、顧客が既に問題に気付いた後にSLO違反を発見することになります。
最初のSLOを間違った数値なしに設定する方法
最も一般的な間違いは測定を確立する前に目標から始めることです。正しい順序でアプローチすることが重要です。
ステップ1：SLIを明確に定義します。 「可用性」という曖昧な定義ではSLIではありません。「エラーステータス以外のHTTPリクエスト（2xx/3xx）、すべてのHTTPリクエストで除算」という具体的な定義がSLIです。測定は既に持っているテレメトリから生成できる必要があります。「すぐに計測する」と約束することは、SLOにデータソースがないことを意味し、実装不可能です。
ステップ2：過去のデータをしっかり取得します。 最後の60〜90日のSLIデータを見てください。SLIは実際にはどのように分布しているか、最も悪い日は何だったか。これは今日達成可能な現実的な目標とウィンドウ内の最初の違反までの余裕がどのくらいあるかを教えてくれます。
ステップ3：測定ウィンドウを戦略的に設定します。 ローリング30日ウィンドウが最も一般的で、応答性が高く、常に最新のデータを提供します。カレンダー月ウィンドウは月の境界で急激な崖の効果を作成するため、実装は難しいです。7日のローリングウィンドウは敏感ですが、信頼性の筋肉をまだ構築しているチームには頻繁にトリガーする傾向があります。
ステップ4：インシデント対応に必要になる前にエラー予算ポリシーを書きます。 チームは重大でない変更を停止するエラー予算バーンレートはどのくらいですか？バーンレートが高まると、オンコールはエスカレートしますか？これらの判断基準をインシデント中ではなく事前に文書化することが重要です。
ステップ5：複数サービスではなく1つのサービスから始めます。 15のサービスのSLOを一度に定義することは、誰も見ないし理解しない15のダッシュボードを生成するだけです。最もユーザーに見える重要なサービスから始めて、1四半期間運用し、データから学んで調整してから、他のサービスに拡張します。
測定ウィンドウオプションとそのトレードオフを理解することが実装の成功を左右します。
7日ローリング：高速フィードバック、短いインシデントに敏感、ただしアラート疲労を作成しやすい
30日ローリング：最も一般的で、シグナルとノイズのバランスが最適
90日ローリング：バッチジョブのような頻繁ではなく重要な運用に役立つ
実際の導入例として。eコマースAPIの場合、最初のSLOを「ローリング28日ウィンドウで測定される95%の/checkoutへのリクエストが成功し、500ミリ秒以内に返すこと」として設定する方法があります。これにより、具体的なSLI（成功率と遅延の組み合わせ）、具体的な目標（95%）、定義されたウィンドウ（28日間）を確定できます。そこからエラー予算を計算します。1日あたり200,000リクエストを受け取る場合、月次エラー予算は概ねSLOが違反される前に280,000の失敗したリクエストです。
SLO監視がコードベース改善作業とどのように接続するか
予想より速くバーンするエラー予算は、インフラストラクチャの問題であるより頻繁にはコードベース内部の問題です。レイテンシスパイクは、コードレビューで気付かなかったN+1クエリまで遡及します。可用性の低下は、特定の負荷の組み合わせの下でのみトリガーするコードパスのnullポインタ例外に原因があります。SLOはこれらの症状を検出し、警告を鳴らします。しかしコードベース自体がその根本的な原因を含んでいます。
重要なのは「アラートが発火する」から「根本原因が特定される」までの時間が実際の制約になるということです。チェックアウトサービスがエラー予算の30%を3日間で消費していて、オンコール エンジニアが150,000行のモノレポで再試行ロジックの動作を変更した箇所を検索して異なる理由を見つけるのに時間がかかる場合、SLOは正しく仕事をしています。しかし根本原因分析のツールが不足しているのが問題です。
最近の調査によると、彼らの監視スタックの隣にAI支援のコードベース検索を計器したチームは、インシデント中に診断までの時間が著しく短いことを報告しています。支払いサービスが503応答の再試行を処理するコード箇所を自然言語で問い合わせることは、数秒で関連する関数を表示します。これは5つのファイルとConfluenceページの1つを手動で読むのに20分かかるのと比較したときの差です。43分のエラー予算ウィンドウがコード検索に費やされるのではなく、実際の問題の修正に費やされます。
チームがSLOを間違える4つの一般的なパターン
多すぎるSLOを定義する。 12個のSLOを同時に追跡するチームは、2ヶ月以内にアラートをバックグラウンドノイズとして扱い始めます。10人のエンジニアのチームのために、3〜5個のSLOが最も重要なユーザー向けの動作に焦点を当てた現実的な上限です。より多く必要な場合、層で構成します。エラー予算ポリシーをトリガーする重要なSLOと、情報目的のSLOに分離するのです。
インフラストラクチャメトリクスを測定し、ユーザーエクスペリエンスを測定しない。 CPUの使用率、メモリ使用量、ディスク I/O は有用なデバッグシグナルです。しかし、ユーザーが見える劣化に直接関連することを証明できない限り、これらは悪いSLIです。代わりにユーザーが経験することを測定してください。リクエスト成功率、P95またはP99のレスポンスタイム、最初の意味のあるデータがレンダリングされるまでの時間です。
運用コスト分析なしにSLOを設定する。 99.99%の可用性の達成には、通常、アクティブな冗長性、マルチリージョンのフェイルオーバー、および任意の時間にすぐにオンコールレスポンスが必要です。チームが持続可能にその方法で運用することはできない場合、SLOは定期的に違反されてから無視されます。違反され無視されたSLOは、SLOがない場合より悪い結果を生みます。チーム全体を信頼性アラートを却下する文化に訓練することになるからです。
消費されたエラー予算データを個人の責任割り当てに使用する。 消費されたエラー予算への最初の応答が「それを引き起こしたシップの変更は誰が承認したか」を特定していることであれば、チーム全体の報告は誠実ではなくなります。エラー予算はチームリソースです。予算が減少しているときの質問は「どれを修正するか」であるべきです。「誰が責任ですか」ではなく。
組織の健康を測定するテストです。工学のすべてのハンズの会議での現在のエラー予算ステータスを共有できますか？それは政治的な議論や個人的な批判をトリガーするのか？その場合、SLO周辺の組織文化は数値的なターゲット自体より多く注意と改善が必要です。信頼性メトリクスは、チームが問題の報告が個人的なリスクを作成しないことを信頼するときにのみ、本当の意思決定ツールとして機能します。
SLOは年に1回ではなく四半期ごとにレビューと調整が必要
SLOを一度設定することは1回限りのキャリブレーション作業ではなく、継続的なプロセスです。サービスは時間とともに変わり、トラフィックパターンはシフトし、与えられた信頼性レベルを維持するための運用コストは変わります。
90日ごとに4つの質問を実行してレビューを行うべきです。
SLOは期間中保有されていましたか。 はいの場合、ターゲットが厳しすぎて現実的でない可能性があります。締め付けることを示唆しているかもしれません。
エラー予算は完全に消費されましたか。 はいなら、どのインシデントがそれを駆動しましたか。
SLOは有用で実行可能なシグナルを表面化しましたか、それともチームはエラー予算ポリシーを頻繁にオーバーライドしましたか。
測定ウィンドウはサービスの使用方法に対して引き続き適切で現実的ですか。
チームが1四半期の間にエラー予算ポリシーをオーバーライドしたことが2回以上ある場合、SLOはおそらくキャリブレーションが外れています。ターゲットが厳しすぎるか、ウィンドウが短すぎるか、測定がユーザーが実際に経験することを正しく反映していません。
SLOはキャリブレーションツールです。信頼性が向上し、トラフィックが増加し、ビジネスのダウンタイムへの許容度が変わるにつれて調整されることを意図しています。四半期ごとにSLOをレビューおよび調整するチームは真の意味での信頼性慣行を実行しています。一度設定してからタッチしていないチームには、組織内で誰にも意味がない数字を持つダッシュボードがあるだけです。