エラーバジェット入門：SLO/SLI/SLAの違いと実務手順

主要用語（定義）

以下は本記事で使う主要用語の定義です。SLO運用では用語の解釈差が運用判断に影響するため、ここで統一しておきます。実務上必要なポイントに絞って短く示します。

• SLI（Service Level Indicator）: サービスの品質を定量化する観測指標。例：HTTP成功率、p99レイテンシ。
• SLO（Service Level Objective）: SLIに対する達成目標（例：99.9%／30日）。内部合意の運用目標。
• SLA（Service Level Agreement）: 顧客との契約上の約束。罰則や補償が含まれる点でSLOと異なる。
• エラーバジェット: SLO未達を許容できる量。通常は許容不良割合×評価ウィンドウで表現する。
• バーンレート（burn rate）: エラーバジェット消費速度。観測された不良割合を許容不良割合で割った値。
• 評価ウィンドウ（evaluation window）: SLOを評価する期間（例：rolling 30d）。
• 計測欠落（unknown）: メトリクスが不足・欠落している状態。取り扱いはポリシーで明確化する。
• カーディナリティ（cardinality）: ラベルの個数やユニーク度。高いと集計コスト・誤集計リスクが増す。

エラーバジェットとは：目的とSLO/SLI/SLAの違い

エラーバジェットはSLOの未達許容範囲を可視化して、リリースや改修の判断材料に使います。事業側と技術側が共通の判断軸を持つことで、過度な信頼性偏重や無秩序なリリースを防げます。

基本概念

ここでは主要な役割を端的に説明します。SLOは内部目標、SLAは顧客向け契約であり責任範囲が異なります。

• SLIは計測可能であることが前提です。
• SLOは経営・プロダクトの合意が必要です。
• SLAは法務・契約の観点で扱い、SLOとは別の承認フローを要求します。

SLOとSLAの契約上の違いと注意点

SLAはペナルティや補償に直結するため、SLOや計測の除外を行う際には法務や契約担当の承認が必要です。計測欠落をSLO評価から除外する運用は、顧客向けSLAに影響を与える可能性があります。除外基準・承認フロー・記録方法を必ず文書化し、監査できる形で保管してください。

SLOをビジネス要件から決める：利害関係者の合意形成

SLOは技術目標であると同時にビジネス判断です。事業インパクトの評価と関係者合意を最初に得ることが成功の鍵になります。

合意形成の進め方

合意形成はワークショップ形式で行うのが効率的です。重要なユーザーフローとビジネスインパクトを起点にSLO案を作ります。

• 重要なユーザーフローを洗い出す（例：会員登録、課金）。
• 影響の定量化（収益影響、契約違反リスク等）を行う。
• 過去30〜90日のSLI分布で現状把握を行う。
• 保守的案／現実案／成長案を作り、効果とコストを比較する。
• PM、SRE、開発、営業でワークショップを実施し、最終承認を得る。

RACIとレビュー頻度

役割分担とレビュー体制を明確にします。書面で決定理由と代替案を残すことが重要です。

• Responsible：SREチーム（観測実装・アラート運用）
• Accountable：サービスオーナー（最終承認）
• Consulted：プロダクト/営業/法務（必要に応じて）
• Informed：経営/カスタマーサポート

レビュー推奨頻度（例）:

• 試験運用中：週次レビューと短い振り返り
• 安定運用：月次ダッシュボード確認、四半期で妥当性レビュー

実務ステップ：SLI選定→SLO設定→エラーバジェット算出

ここでは優先順位と注意点を示します。まずはインパクトの大きいSLIを1つ選び、短期で試すことを推奨します。

成功率（binary）のSLI

成功率は定義が単純で解釈が容易です。リトライやCDNキャッシュの扱いを事前定義します。

• 指標例：http_requests_success_total / http_requests_total。
• 要件：成功・失敗の判定基準を明確にする（例：HTTPステータス、ビジネスロジックの判定）。
• 注意点：リトライのカウント方法、キャッシュヒットの扱い、サンプリングの有無を定義する。

レイテンシ（分位点）のSLI

レイテンシはユーザー体験に直結しますが、分位点の算出方法に注意が必要です。

• 指標例：p95・p99の応答時間。ヒストグラムで収集するのが望ましい。
• 要件：bucket設計、集計ウィンドウ、遅延補正（後着データ）を決める。
• 注意点：短期ウィンドウでのノイズ対策と、ウィンドウ長の整合性確認を行う。

整合性／完全性（データの正確さ）

データ品質系はユーザー信頼に直結します。欠損や重複の定義を明確にします。

• 指標例：書き込み成功率、複製ラグ、データのfreshness。
• 要件：再試行ポリシーの扱い、遅延データの許容、検証方法を定義する。

バッチ処理向けのSLI

バッチ系は完了率や遅延分布が主要指標です。再実行のポリシーとSLO設計を揃えます。

• 指標例：日次ジョブ成功率、完了遅延（分布）。
• 要件：再実行を除外するか含めるか、評価ウィンドウの定義を明確にする。

エラーバジェット算出と前提（例示）

SLO算出は前提の整備が最も重要です。例示は実務導入時の確認項目を含めて示します。

時間ベース（許容ダウンタイム）

時間ベースで表現すると直感的です。計算式とサンプルを示します。

• 計算式：許容ダウンタイム = (1 - SLO) × ウィンドウ長
• 例（前提注記あり）：SLO = 99.9%、ウィンドウ = rolling 30日（30×24×60 = 43,200分）
  → 許容ダウンタイム = 0.001 × 43,200 = 43.2分

注記：この例は「評価ウィンドウをUTCベースの連続30日」とする前提です。評価ウィンドウ定義、タイムゾーン、遅延データ扱い、リトライの扱いなどを必ず明記してください。

リクエストベース（許容エラー数）

トラフィック量で許容エラー数を算出する方法です。前提（最小サンプル数等）を明示します。

• 計算式：許容エラー数 = 総リクエスト数 × (1 - SLO)
• 例（前提注記あり）：1日10,000,000リクエスト、SLO=99.9% → 許容エラー = 10,000/日

前提注記：リクエストの定義（ユーザーリクエストか内部リトライを含むか）や、最小サンプル数（例：ウィンドウ内総リクエスト > 1,000）を明示してください。

バーンレートの考え方と複数ウィンドウ運用

バーンレートはエラーバジェット消費の速度を示します。短期・長期の複数ウィンドウを監視するのが実務的です。

• 定義例：バーンレート = 観測不良割合 / 許容不良割合 = (1 - observed_SLI) / (1 - SLO)
• 例：SLO=99.9%（許容不良割合=0.001）、直近で不良割合=0.005 → バーンレート = 5

しきい値の例（あくまで例示、組織による調整と承認が必要）:

• バーンレート > 1：通知（調査開始）
• バーンレート >= 2：即時調査・リリース停止の検討
• バーンレート >= 4：主要な緩和措置（リリース停止等）を実行検討

必ず導入前に事業側・リスク管理・法務のレビューと承認を取ることをルール化してください。

算出時の必須前提（明示すること）

算出例を実運用で使う前に、以下を明確にしてください。

• 評価ウィンドウの厳密定義（rolling 30d か calendar month か）
• タイムゾーン（UTC推奨）と集計境界
• リトライや重複の扱い（成功カウントの定義）
• 最小サンプル数条件（ウィンドウ内の最小リクエスト数）
• 遅延データの補正ルール（後着データを許容するか否か）
• 四捨五入・表示精度のルール

観測と計測の実装ベストプラクティス（Prometheus/Datadog/GCP等）

観測はSLO運用の土台です。原データを保存し、メトリクス品質の検知を自動化してください。計測品質が悪いとSLO運用は意味をなさなくなります。

基本方針（原データ保持とクライアント視点）

原データを保存してから派生指標を算出します。クライアント視点の観測を優先し、内部メトリクスだけで判断しない方針が重要です。

• カウンタとヒストグラムを原データとして保持する。
• 集計ルールはコード化して再現可能にする。
• クライアント視点（エンドツーエンド）を優先する。

メトリクス品質管理：欠損・遅延・サンプリング・ラベル設計

計測品質を継続監視する仕組みを作ります。検出・分類・エスカレーションの流れを定義してください。

• 欠損検出：エクスポーターの up メトリクスやメトリクス数の急減を監視する。
• 遅延対策：後着データを許容する遅延ウィンドウを定義する。
• サンプリング：サンプリング率をメトリクス化し、補正が必要なら算出パイプラインで補正する。
• ラベル設計：サービス/環境/リージョン程度に留め、高カードーディナリティを避ける。
• 例：メトリクス総数が平常比で50%未満が10分継続したら品質アラートを出す（あくまで例）。

テストと検証

本番に導入する前に必ずテストを行います。合成トラフィックやフォールトインジェクションでパイプラインを検証してください。

• 合成リクエストでSLI算出の期待値と実測を照合する。
• フェイルオーバーや遅延ケースで算出ロジックを検証する。
• 期待値と乖離したケースは根本原因を特定し、修正を反映する。

実装参考例（OpenSLO / PromQL / Datadog） — 参考例であり実運用前に要検証

以下は説明目的の参考例です。実運用でそのままコピー＆ペーストすると誤動作するリスクがあります。導入時は必ず下記のチェックポイントを確認し、ステージングで検証してください。

参考：OpenSLO（概念例）

参考：Prometheus（参照用PromQL）

参考：Datadog（概念例）

実装時の確認ポイント（必須）:

• ラベル整合性：分子と分母でラベルセットを一致させる。
• 集計ウィンドウ：PromQLの[5m]等を業務要件に合わせる。
• スクレイプ間隔とbucket設計：ヒストグラムのbucketが適切か確認する。
• 遅延データ補正：ログ由来メトリクスは後着データをどう扱うかを決める。
• 最低サンプル数条件：ウィンドウ内の最小件数を設ける。
• テスト：ステージングで合成トラフィックによる期待値検証を行う。
• ドキュメント化：算出式、前提、検証結果を必ず残す。

公式ドキュメント（Prometheus、Datadog、OpenSLO等）に従い、環境固有のパラメータを確認してください。

バーンレート、アラート設計と自動化アクション

バーンレートとアラートの設計はインシデント対応の起点になります。自動化は利便性とリスクのバランスで設計してください。

バーンレートの定義と計算式

バーンレートは現在の不良割合がSLOの許容値の何倍かを示します。導入時に式と用語を統一してください。

• 式：バーンレート = 観測不良割合 / 許容不良割合
• 同義式：バーンレート = (1 - observed_SLI) / (1 - SLO)

しきい値の例（組織依存である旨の明示）

しきい値や自動化アクションは組織のリスク許容度によって変えます。以下は例示です。導入前に事業側・リスク管理のレビューと承認を必須としてください。

• 例：バーンレート > 1 → 通知（調査）
• 例：バーンレート >= 2 → リリース停止を検討（承認プロセス必須）
• 例：バーンレート >= 4 → 強い緩和（トラフィック制限等）を検討

アラート設計の実務ポイント

アラート設計は誤検知と見逃しのバランスが重要です。メトリクス品質アラートを先に出す設計が有効です。

• マルチウィンドウ監視を行う（例：5m、1h、24h）。
• 最低リクエスト数条件を付けてノイズを低減する。
• アラートレベルを階層化（情報・調査要請・操作要請）。
• メトリクス品質アラートを先に出して誤報を防ぐ。

自動化アクション設計（安全優先）

自動化は業務効率化に有効ですが、安全性を優先してください。重大な操作はヒューマンインループにすることを推奨します。

• 自動化して良い例：CI/CDでの自動ブロック、フィーチャーフラグの即時無効化、オートスケールのトリガー。
• ヒューマンインループ推奨：自動ロールバック、クリティカルなトラフィック遮断。
• 必要事項：実行者、事前承認フロー、取り消し手順、通知テンプレート、ロールバック手順を文書化する。

自動化導入前に試験運用とフェイルセーフ設計を行い、関係者の承認を得てください。

エラーバジェットポリシー、運用フロー、試験運用プラン

ポリシーは例外ルールや承認フローを含めて明文化します。まずテンプレート化し、短期の試験運用で運用性を検証してください。

ポリシーテンプレート（必須項目）

ポリシーに含めるべき必須項目を示します。組織の運用ルールに合わせて埋めてください。

• サービス名
• オーナー（SRE/PM/チーム）
• SLI定義（計測方法、メトリクス名、集計ウィンドウ、ラベル）
• SLO値と評価ウィンドウ（例：99.9% / 30日）
• エラーバジェットの表現（時間ベース／リクエストベース）
• バーンレートしきい値と対応（例示を明記）
• 停止基準／リリース権限（誰が停止できるか）
• エスカレーション手順（連絡先・代替手段）
• 例外申請とレビューの流れ（承認者、記録方法）
• メトリクス品質基準と対応（欠損時ハンドリング）

テンプレートはYAMLやIssueテンプレートで管理し、変更履歴を残してください。

運用フローと1週間試験運用プラン（例）

運用フローは検出→初動→対応→復旧→事後対応の流れをシンプルに定めます。1週間の試験運用で閾値や運用負荷を検証します。

運用フロー（簡潔）: 検出 → 初動（切り分け） → 一時処置 → 復旧 → ポストモーテム → SLO見直し

1週間試験運用プラン（例）:

• Day0（準備）: SLIを1つ選定。監視パイプラインの動作確認。
• Day1: メトリクス収集開始、ダッシュボード作成。
• Day2–3: ベースライン測定、短期ウィンドウの挙動確認。
• Day4: SLOとエラーバジェットを算出、アラートを設定。
• Day5–7: 試験運用。毎日15–30分の振り返りで閾値を調整。

評価指標（KPI）: SLI実測値、残エラーバジェット、バーンレート、インシデント数、MTTR、リリースブロック回数。

計測欠損の除外基準・承認フロー・記録方法

計測欠落をSLO評価から除外する運用は、明確な基準と承認プロセスを必須化してください。特に顧客向けSLAがある場合は法務承認が必要です。

手順（推奨フロー）:

1. 検出：自動監視で欠損を検知（例：exporter up が false、メトリクス数が閾値未満）。
2. 一次調査：SREが原因を切り分け（エクスポーター障害、ネットワーク等）。
3. 例外申請：開始時刻・終了時刻（想定）・影響範囲・証拠を添えて申請チケットを作成。
4. 承認：サービスオーナーの承認を必須とする。SLA影響がある場合は法務／契約担当の追認を得る。
5. 記録：承認記録、メトリクスエクスポート、ログ、ダッシュボードスナップショットをチケットに添付。監査可能な場所に保存する。
6. SLO反映：承認が出た場合のみ自動/手動でSLO評価から除外するルールを適用する。未承認の場合はunknown扱いまたは失敗扱いとする運用を事前定義する。
7. レビュー：ポストモーテムで原因と再発防止策を検証する。

記録は検索可能なチケットやリポジトリに残し、定期的に監査してください。

ケーススタディ（API／バッチ／ストリーミング）

数値は教育目的の例です。必ず前提を明示して運用に合わせて調整してください。

• APIサービス（リクエストベース）
• SLI: HTTP成功率（2xx）
• SLO: 99.9% / 30日（評価ウィンドウはrolling 30d、UTC基準）

• 前提: リトライは同一ユーザー要求として集計しない。最小サンプル数はウィンドウ内1000リクエスト。

• バッチ処理（ジョブベース）

• SLI: 当日ジョブ成功率（再実行を除く）
• SLO: 98% / 日（ジョブ数が少ない場合は別指標を検討）

• 前提: 再実行ポリシーをSLO定義書に明記。

• ストリーミング（遅延・欠損）

• SLI: エンドツーエンド遅延 p99 < 5s の割合
• SLO: 99.9% / 7日（短めのウィンドウで遅延を捉える）
• 前提: 欠損率と遅延は別SLOで評価し、総合判断を行う。

参考資料・公式ドキュメント（該当ページを中心に）

公式ドキュメントや仕様の該当ページを参照し、実装時は最新ドキュメントを確認してください。以下は代表的な参照先です。

• Google SRE Book — Service Level Objectives（SLOの章）
  https://sre.google/sre-book/service-level-objectives/

• Google SRE Book — Error Budgets（エラーバジェット関連の章）
  https://sre.google/sre-book/error-budget/ （SREブック内の該当章を参照）

• Prometheus — Recording rules（recording ruleの設定）
  https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/

• Prometheus — Alerting rules（アラートルール）
  https://prometheus.io/docs/alerting/latest/alerts/

• Prometheus — Functions: histogram_quantile（p99算出）
  https://prometheus.io/docs/prometheus/latest/querying/functions/#histogram_quantile

• Datadog — Service Level Objectives（SLO機能のドキュメント）
  https://docs.datadoghq.com/service_level_objectives/

• OpenSLO — Spec / Documentation（宣言的SLO定義）
  https://openslo.dev/ または https://github.com/openslo/spec

• Google Cloud — Service Level Objectives（Cloud MonitoringのSLOドキュメント）
  https://cloud.google.com/monitoring/slo

• AWS — Well-Architected Reliability Pillar（信頼性設計の指針）
  https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html

参照元の該当章や関数ページを実装時に確認し、例示コードやクエリは環境に合わせて調整してください。

まとめ

SLOとエラーバジェットは、信頼性と開発速度を両立するための有力な枠組みです。以下を優先して進めてください。

• まずはユーザー体験に直結するSLIを1つ選び、ステージングで試験運用する。
• SLOはビジネス影響から逆算し、複数案で合意を取る。決定は文書化して残す。
• エラーバジェット算出では評価ウィンドウ・リトライ扱い・最小サンプル数等の前提を必ず明記する。
• 計測欠損の除外は法務・サービスオーナー承認を必須化し、記録と監査可能性を担保する。
• バーンレートや自動化のしきい値は例示に留め、導入前に事業側・リスク管理のレビューを行う。
• 実装例は参考例として扱い、ラベル整合性・集計ウィンドウ・遅延補正等の確認を行ってから本番導入する。
• 企業向け配布時はブランド表現や責任範囲、サポート体制、免責事項を別途明記して運用ガイドと合せて配布する。

まずは対象サービスでSLIを一つ選び、1週間の試験運用プランで動作と運用工数を検証してください。