# Alerting on SLOs Navigation: [[index]] | [[overview]] ## 概要 SLO をオンコールエンジニアが対応すべき具体的なアラートルールへ変換する章である。SLO とエラーバジェットが顧客体験ベースの最良の通知条件だという前提に立ち、単純な短期エラー率閾値から、複数ウィンドウ・複数バーン率の推奨構成までを段階的に比較する。 この章の中心は、「アラートはエラー率の異常ではなく、エラーバジェットへの重大な脅威に対して出す」という設計原則である。評価軸は精度、再現率、検知時間、リセット時間の 4 つであり、これらを同時に制御するために、長い窓で重大性を確認し、短い窓で現在も燃焼中かを確認する。 ## 主要主張 - SLO ベースアラートの目的は、エラーバジェットを大きく消費する重大イベントを、予算消費前に通知することである。 - 短い窓で SLO 閾値を超えたら即ページする方式は実装が簡単だが、短時間の軽微な事象に過敏で、重大性を表せない。 - 長い窓だけで精度を上げる方式は、検知時間とリセット時間が長くなり、解決後もアラートが残りやすい。 - `for` のような持続時間句で長い窓を代用すると、重大障害も軽微障害も同じ待ち時間になり、100% 障害を 1 時間見逃すなど再現率と検知時間が悪化する。 - バーン率は SLO に対してどれだけ速くエラーバジェットを消費しているかを表す。99.9% / 30 日 SLO では、バーン率 1 が 30 日で予算を使い切る速度、バーン率 1000 が 43 分で使い切る速度である。 - 推奨開始点は、ページ用に 1 時間 2% 予算消費と 6 時間 5% 予算消費、チケット用に 3 日 10% 予算消費を置く設計である。 - さらに短窓を長窓の 1/12 程度に置き、長窓と短窓が同時に閾値を超えるときだけ通知すると、精度とリセット時間のバランスが改善する。 - 低トラフィックでは 1 件の失敗が過大なバーン率になりうるため、人工トラフィック、関連サービスの集約、リトライやフォールバック、SLO の再設定を検討する。 - 99.999% のような極端に高い可用性目標では、100% 障害が 26 秒で予算を使い切るため、アラートで守るのではなく、カナリアリリースなど設計で全停止確率を下げる必要がある。 - 大規模環境ではサービスごとに個別のバーン率・窓を設計するとトイルが増えるため、リクエスト種別を CRITICAL / HIGH_FAST / HIGH_SLOW / LOW / NO_SLO のようなバケットにまとめる。 ## 章の構造 ### アラート評価軸 - 精度: 検知されたイベントのうち重大イベントである割合。 - 再現率: 重大イベントのうちアラートされた割合。 - 検知時間: 通知までの時間。長いとエラーバジェット消費が進む。 - リセット時間: 解決後にアラートが残る時間。長いと混乱や無視を招く。 ### 6 つのアプローチ 1. 短期エラー率が SLO 閾値を超えたら通知する。単純だが重大性を反映しにくい。 2. 長い窓でエラー率を評価する。精度は上がるが検知とリセットが遅い。 3. 持続時間句を使う。重大障害でも待ち時間が固定で、瞬間的に正常化するとタイマーがリセットされる。 4. 単一バーン率で通知する。固定量の予算消費に基づけるが、やや低いバーン率を見逃す。 5. 複数バーン率でページとチケットを分ける。再現率と優先度付けが改善するが、重複通知抑制が必要になる。 6. 複数ウィンドウ・複数バーン率にする。長窓で重大性、短窓で現在進行中かを確認し、バランスが最もよい。 ### 低トラフィックサービス - 10 リクエスト/時のサービスでは 1 失敗が 10% エラー率になり、99.9% SLO では 1000 倍バーン率として即ページ対象になりうる。 - 対策は、人工トラフィック、関連サービスの上位集約、ユーザー影響を下げるプロダクト変更、SLO の再交渉である。 - 人工トラフィックは既存のブラックボックスプローブや統合テストを活用できるが、実ユーザーだけが影響を受ける障害を隠す危険もある。 ### 極端な可用性目標 - 低い可用性目標では、2%/1 時間のようなページ条件がそもそも発火しない場合がある。 - 高すぎる可用性目標では、予算が秒単位で枯渇するため、アラートは SLO 防衛には遅すぎる。 - 高可用性では、カナリア展開や段階的露出により、障害が全ユーザーへ一気に広がる確率を下げる設計が重要である。 ### 大規模アラート管理 - 個別サービス・個別リクエストに固有の窓とバーン率を設定すると、認知負荷とトイルがスケールしない。 - 近い可用性・レイテンシ要求を持つリクエストを少数バケットへまとめると、ユーザー幸福を守る粒度と運用可能性のバランスが取れる。 ## 既存 SRE Book との関係 - [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]] の SLO/SLI/SLA とエラーバジェット概念を、実際の Prometheus 風アラート式へ落とす章である。 - [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]] のアラート実践を、SLO とバーン率中心へ更新・特化した続編として読める。 - [[@2016__OReilly__SRE Book - Chapter 29 Dealing with Interrupts]] と接続する。ページとチケットの使い分けは、オンコール割り込みを重大イベントへ制限するための設計である。 - [[@2016__OReilly__SRE Book - Chapter 5 Eliminating Toil]] とも接続する。アラートパラメータの個別最適化はトイル化するため、バケット化が推奨される。 ## 重要概念候補 - [[SLOベースアラート]]: SLO/SLI とエラーバジェットから重大イベント通知を設計する概念。新規 concept 候補。 - [[エラーバジェットバーン率]]: SLO に対する予算消費速度。[[エラーバジェット]] の横断知見へ追加候補。 - [[複数ウィンドウ複数バーン率アラート]]: 長窓と短窓、ページとチケットを組み合わせる推奨実装。新規 concept 候補。 - [[低トラフィックサービスのアラート]]: サンプル数不足による過敏さと、人工トラフィック・集約・プロダクト変更の設計。 - [[リクエストクラスバケット]]: CRITICAL / HIGH_FAST / HIGH_SLOW / LOW / NO_SLO のように SLO 対象を管理可能な粒度へまとめる。 - [[アラート精度と再現率]]: 重大イベント検知の評価軸としての精度・再現率・検知時間・リセット時間。 ## 実体候補 - [[Google SRE]] - [[Prometheus]] - [[Steven Thurgood]] - [[Jess Frame]] - [[Anthony Lenton]] - [[Carmela Quinito]] - [[Anton Tolchanov]] - [[Nejc Trdin]] ## 統合時に更新すべき既存ページ候補 - [[サービスレベル目標]]: SLO をアラートルールへ変換する手順と、SLO が顧客体験ベースの通知条件になる点を追加。 - [[エラーバジェット]]: バーン率、ページ/チケット閾値、低トラフィック・極端な可用性目標での制約を追加。 - [[テレメトリ]]: SLI メトリクスと窓関数計算が SLO アラートの前提になる点を追加。 - [[インシデント管理]]: ページとチケットの使い分け、検知時間とリセット時間が対応行動に与える影響を追加。 - [[トイル]]: アラート設定の個別化がスケールしないトイルになるため、バケット化が必要という知見を追加。 ## 未解決の問い - 複数ウィンドウ・複数バーン率アラートは、リクエスト駆動サービス以外、たとえばバッチ処理や非同期パイプラインではどのように変形すべきか。 - LLM エージェントがオンコール一次対応を担う場合、ページ/チケットの境界は人間への割り込み境界から、エージェント権限境界へどう移るか。 - 低トラフィックサービスの人工トラフィックは、実ユーザー信号を隠す副作用をどう評価すべきか。 ## 出典 - Raw: `.raw/articles/alerting-on-slos-2026-06-07.md` - URL: https://sre.google/workbook/alerting-on-slos/