slo-error-budget

SLO とエラーバジェットのスキル

サービスのための、実装可能で完全な SLO ドキュメントを作成します。測定対象、設定する目標、エラーバジェットの計算方法、バジェットが消費されたときの対応を網羅します。

優れた SLO は達成すべき目標ではありません。ユーザーにとっての信頼性の意味を定める合意であり、信頼性と開発速度の間で原則に基づくトレードオフを行うためのフレームワークです。

このドキュメントの位置付け — 背骨の枠組み

これはインシデント対応の背骨を統括します。slo-error-budget (frame) → /debugging-log-analyser → /incident-postmortem → /oncall-runbook。ループ全体の基準となるエラーバジェットを設定します。これは、ポストモーテムのアクションアイテムに今すぐ取り組むべきか（バジェット消費済み）、後回しにできるか（バジェットに余裕あり）を後で判断する、目標達成のための強制力です。共通用語（SLO、エラーバジェット、インシデント、アクションアイテム）は、docs/craft/incident-response.md で一度だけ定義されています。

ループ

SLO は、ユーザーのニーズに基づかず、願望的な目標になっている場合や、バジェットに実効性がない場合に機能しません。フェーズ 1 は土台となる部分です。「100% から少し引く」という発想で選んだ目標では、何も守れません。

1. 100% ではなく、ユーザーのニーズから目標を導きます。 ユーザーが実際に体感するもの（成功率、レイテンシ、鮮度）を追跡する SLI を選び、ユーザーが必要とする水準、つまり、それ以上の信頼性がユーザーにとって重要でなくなる水準を目標に設定します。 完了条件： 各 SLO の目標が、明示されたユーザーニーズに結び付いており、100% の目標や、見栄えのよさだけで選ばれたきりのよい数値がないこと。
2. 目標を数値に基づいてバジェットに変換します。 エラーバジェット（対象期間における 100% から SLO を差し引いた値）を、誰も実感できないパーセンテージではなく、リクエスト数、分数、イベント数などの具体的な許容量として算出します。 完了条件： 対象期間のバジェットが数えられる許容量として表され、消費しきる前にバーンレートアラートが発報すること。
3. バジェットに実効性を持たせます。ポリシーこそが重要です。 各バジェット水準で何が変わるかを明記します。正常 → リリースする、リスクあり → ペースを落として補強する、枯渇 → 機能開発を止めて信頼性を改善する。ポリシーのないバジェットは、誰も従わないダッシュボードにすぎません。 完了条件： 各バジェット水準に、チームが実際に従う具体的で実効性のある結果が明記されていること。実際に機能開発を凍結するトリガーも含まれます。
4. ループを統括するものとして引き継ぎます。 このバジェットが、/incident-postmortem のアクションアイテムの優先順位を決めることを明記します。バジェットを消費した場合は緊急対応とし、バジェットに余裕がある場合は後回しにできます。 完了条件： 後続のループで、信頼性の目標を再検討せずに、このバジェットを使ってアクションアイテムの緊急度を判断できること。

必要な入力情報

以下の情報がまだ提供されていない場合は、確認してください。

• サービス名と機能の簡単な説明
• 主なユーザー — このサービスに依存するのは誰で、どのように利用しているか
• 保護対象のユーザー向けインタラクション — 例：API 呼び出し、ページ読み込み、トランザクション
• 現在の信頼性データ — エラー率、レイテンシ、稼働率（可能であれば直近 30～90 日分）
• 既存のオンコール体制 — アラートに誰が対応するか
• デプロイ頻度 — チームがどれくらいの頻度でリリースするか
• 顧客との既存の SLA — SLO の目標に制約を与えます

主な定義

SLO を作成する前に、必ず以下を定義してください。

用語	定義
SLI（サービスレベル指標）	測定する指標 — 例：「500ms 未満で正常に完了したリクエストの割合」
SLO（サービスレベル目標）	その指標の目標 — 例：「リクエストの 99.5%」
SLA（サービスレベル契約）	顧客に対する契約上の約束 — SLO よりも緩い水準にする必要があります
エラーバジェット	100% を下回ることが許容される余裕 — 計画的および計画外のダウンタイムに使えるバジェット
バーンレート	エラーバジェットが消費される速度

---

出力形式

---

SLO ドキュメント：[サービス名]

サービス： [名前] | チーム： [チーム名] オーナー： [名前／役割] | 承認者： [名前] 適用日： [日付] | レビュー日： [日付 + 3 か月] バージョン： [1.0]

---

この SLO が必要な理由

［2～3 文。どのような信頼性の問題を解決するのでしょうか？ この SLO が必要になる前に、どのようなことが起きていたのでしょうか？ この SLO によって、どのような意思決定が可能になるのでしょうか？］

---

サービス概要

このサービスの役割： ［1 文］ このサービスに依存する対象： ［社内チーム／外部顧客／両方 — 説明］ この SLO で保護する重要なユーザージャーニー：

1. ［ジャーニー 1 — 例：「ユーザーが支払いを完了する」］
2. ［ジャーニー 2］
3. ［ジャーニー 3］

---

SLI — 測定対象

ユーザージャーニーまたは信頼性の指標ごとに SLI を 1 つ定義します。SLI は最大 3～5 個にしてください。

SLI 1：［名前 — 例：リクエスト成功率］

フィールド	詳細
測定内容	［例：「5xx 以外のレスポンスを返した API リクエストの割合」］
良好なイベントの定義	［例：「500ms 以内に完了した、ステータスが 2xx または 4xx の HTTP レスポンス」］
不良なイベントの定義	［例：「ステータスが 5xx の HTTP レスポンス、または 500ms を超えて応答したすべてのリクエスト」］
測定元	［例：「アプリケーションロードバランサーのアクセスログ／Datadog APM／Prometheus」］
測定期間	直近 28 日間のローリングウィンドウ
除外項目	［例：「ヘルスチェック用エンドポイントを除外／計画メンテナンス中のリクエストを除外」］

SLI 2：［名前 — 例：レイテンシ］

フィールド	詳細
測定内容	［例：「/checkout エンドポイントの P99 応答時間」］
良好なイベントの定義	［例：「P99 でリクエストが 500ms 以下で完了する」］
不良なイベントの定義	［例：「P99 でリクエストに 500ms を超える時間がかかる」］
測定元	［測定元］
測定期間	直近 28 日間のローリングウィンドウ
除外項目	［除外項目］

SLI 3：［名前 — 例：データの鮮度／キューの深さなど］

［同じ構成］

---

SLO の目標値

SLI	目標値	期間	エラーバジェット
［SLI 1 の名前］	［X］%	28 日間のローリングウィンドウ	［100 - X］% = ［Y 分／月］
［SLI 2 の名前］	［X］%	28 日間のローリングウィンドウ	［100 - X］% = ［Y 分／月］
［SLI 3 の名前］	［X］%	28 日間のローリングウィンドウ	［100 - X］% = ［Y 分／月］

目標値の設定方法：

• 過去のベースライン（直近 90 日間）：［X］%
• 目標値は、過去のベースラインより［高く／同じ］設定し、［信頼性を向上させる／現在の実態を反映しながらコミットメントを明確化する］
• 根拠：［1～2 文］

100% を目標にしない理由： ［100% を目指すことが逆効果となる理由を簡潔に説明します — 機能開発を妨げ、ユーザーの実情を反映しないため］

---

エラーバジェットの計算

SLI 1（［名前］）の目標値が［X］% の場合：

Error budget = (100% - SLO target) × measurement window
             = (100% - [X]%) × 28 days × 24 hours × 60 minutes
             = [Y]% × [Z total minutes]
             = [N] minutes of allowed failure per 28-day window

簡単に言うと： SLO に違反するまで、直近 28 日間のローリングウィンドウ内で［不良なイベント］が発生しても、［N］分まで許容できます。

---

バーンレートアラート

バーンレートとは、ウィンドウ内のエラーバジェットに対して、どれだけの速さでエラーバジェットが消費されているかを示す値です。 バーンレートが 1 の場合、28 日間でエラーバジェットをちょうど使い切るペースで消費しています。

アラート	バーンレート	期間	重大度	対応
ページ（重大）	>14×	1 時間	P1	直ちにオンコール担当者へ通知 — 2 時間未満で予算を使い切ります
ページ（高）	>6×	6 時間	P2	オンコール担当者へ通知 — 5 日未満で予算を使い切ります
チケット（警告）	>3×	3 日間	P3	チケットを作成 — 次回のチームミーティングで確認します
情報	>1×	28 日間	情報	ログ記録のみ — 期間終了までに予算を使い切るペースです

アラートの実装： ［監視ツールのアラート設定へのリンク — 例：Datadog、Prometheus/Alertmanager、Grafana］

---

エラーバジェットポリシー

このポリシーでは、エラーバジェットが健全な場合と消費が進んでいる場合の両方について、対応方法を定めます。

予算が健全な場合（残り >50%）

• 機能開発とデプロイは通常のペースで進めます
• チームは、よりリスクの高い実験に取り組むことができます
• 信頼性の改善は予定に組み込みますが、緊急対応にはしません

予算が危険な状態にある場合（残り 25～50%）

• デプロイの頻度を下げ、十分にテストされた変更のみをリリースします
• 現在のスプリントに信頼性の改善を 1 つ追加します
• チームのスタンドアップに、週次のエラーバジェットレビューを追加します

予算がほぼ枯渇した場合（残り25%未満）

• 信頼性の改善を優先し、機能開発を一時停止します
• オンコール担当者の明示的な承認なしに、新たなデプロイを行いません
• エラーバジェットの消費率を毎日確認します
• 顧客の期待値を管理するため、CSM／サポートに通知します

予算を使い切った場合（残り0% — SLO 違反）

• すべての機能開発を停止します
• オンコールエンジニアとエンジニアリングマネージャーに直ちに通知します
• 5営業日以内に事後レビュー（PIR）を実施する必要があります
• 根本原因への対処中は、関係者の承認を得て SLO の目標を一時的に緩和する場合があります

---

ダッシュボードとレポート

SLO ダッシュボード： [Datadog／Grafana などのダッシュボードへのリンク]

公開するメトリクス：

• 現在の SLO 達成率（直近28日間）
• 残りのエラーバジェット（%および分）
• 消費率（現在値と推移）
• この期間のインシデント件数と MTTR

レポートの頻度：

対象	頻度	形式
エンジニアリングチーム	毎週	Slack の概要 — #[service]-slo
エンジニアリングマネージャー	毎月	SLO レビュー会議
関係者／顧客	四半期ごと	SLO 達成状況の概要

---

除外事項とエッジケース

計画メンテナンス： 事前告知済みのメンテナンス期間中は、エラーバジェットを消費しません。メンテナンスは [channel] を通じて [X hours] 前に通知する必要があります。

依存関係の障害： SLO 違反が当社の管理外にある上流の依存関係によって発生した場合は、記録してください。ただし、エラーバジェットには算入されます（ユーザーには、当社の障害と依存関係の障害の違いは分かりません）。

不可抗力： [クラウドプロバイダーの障害や大規模なインフラストラクチャー事象に関するポリシー]

---

SLO のレビュー頻度

レビュー	実施時期	担当者	成果物
エラーバジェットのレビュー	毎週	チーム	バジェットの健全性チェック — 消費が速い場合は調整します
SLO 目標のレビュー	四半期ごと	チーム + EM	基準値が大幅に変化した場合は目標を調整します
年次 SLO 監査	毎年	チーム + 関係者	SLI を見直します — 適切な項目を測定できていますか？

SLO 目標を変更するタイミング：

• 過去の基準値が大幅に改善し、目標が実際の信頼性を反映しなくなった場合
• ユーザーのフィードバックから、目標がユーザーの実際の体験と一致していないことが分かった場合
• SLO が不正に利用されている場合（メトリクスは健全でも、ユーザーは不満を抱えている）

---

品質チェック

• SLI はユーザー向けであり、内部システムのメトリクスではなく、ユーザーが体験する内容を測定している
• 正常イベントと異常イベントが明確に定義され、何が算入されるかに曖昧さがない
• 目標は希望的な切りのよい数値ではなく、過去のデータに基づいている
• エラーバジェットポリシーには明確なトリガーと対応策があり、「チームで話し合う」だけではない
• 消費率アラートには異なる時間枠が設定され、急速な消費と緩やかな消費の両方を検知できる
• 除外事項が記録され、SLO の数値を知らないうちに水増ししないようになっている

アンチパターン

• SLO 目標を100%に設定しないでください。機能開発を妨げ、ユーザーが体験する信頼性も反映しません
• 内部システムのメトリクスを SLI として測定しないでください。SLI は内部の CPU やメモリではなく、ユーザーが直接体験する内容を反映する必要があります
• 曖昧なトリガーを含むエラーバジェットポリシーを書かないでください。「チームで話し合う」だけでは実行可能なポリシーになりません。トリガーは具体的な割合で指定する必要があります
• 希望的な切りのよい数値を目標の根拠にしないでください。必ず過去の基準値データから導き出してください
• 消費率アラートの時間枠を1つだけ設定しないでください。時間枠が1つだけでは、急速な消費と、気付かれないまま予算を使い切る緩やかな消費の両方を見逃します