# Google SRE Workbook - Appendix A Example SLO Document Navigation: [[サービスレベル目標]] | [[エラーバジェット]] ## 概要 付録 A は、Example Game Service という架空サービスの SLO 文書例である。対象サービスは、モバイルアプリ、REST API、データストア、スコアパイプライン、公開 HTTP サーバから成る。SLO は 4 週間のローリングウィンドウで評価される。(Source: [[.raw/articles/sre-workbook-slo-document-2026-06-07.md]]) この文書は、SLO が単なる数値目標ではなく、測定点、成功条件、根拠、限界、エラーバジェット発動条件を含む運用上の合意文書であることを示す。 ## SLI/SLO の構造 - API 可用性: ロードバランサメトリクス上で HTTP 5XX 以外を成功とし、97% 成功を目標にする。 - API レイテンシ: 90% のリクエストが 400 ms 以下、99% が 850 ms 以下。 - HTTP サーバ可用性: 99%。 - HTTP サーバレイテンシ: 90% が 200 ms 以下、99% が 1,000 ms 以下。 - スコアパイプライン鮮度: 90% の読み出しが 1 分以内、99% が 10 分以内に更新されたデータを使う。 - スコアパイプライン正確性: correctness prober が注入したレコードの 99.99999% が正しい出力を返す。 - スコアパイプライン完全性: パイプライン実行の 99% が全データを処理する。 ## 主要主張 - SLO はユーザーが経験する価値を複数側面で表す必要がある。単一の可用性だけでは、レイテンシ、データ鮮度、正確性、完全性を捉えられない。 - SLI は「どこで測るか」を明示する必要がある。本例ではロードバランサメトリクスを使うため、ロードバランサに到達しなかったリクエストを測れないという限界がある。 - SLO の根拠は履歴測定と丸めルールから説明できる。API/HTTP の可用性とレイテンシは 2018-01-01 から 2018-01-28 の測定に基づき、可用性は 1% 単位で切り下げ、レイテンシは 50 ms 単位で切り上げる。 - エラーバジェットは目標ごとに独立して定義される。API 可用性 97% なら、4 週間で 1,000,000 リクエストに対して 3% = 30,000 エラーが予算になる。 ## 重要な概念候補 - [[SLO文書]]: SLI/SLO、根拠、但し書き、エラーバジェット方針へのリンクを含む運用合意文書。 - [[ユーザー体験に基づくSLO]]: SLO 値とユーザー体験の相関を検証・未検証の状態込みで扱う設計。 - [[データ鮮度SLO]]: データ処理パイプラインにおける「どれだけ最近のデータか」を SLI/SLO とする考え方。 - [[正確性プローバ]]: 既知の正解を持つ合成データを注入し、処理結果の正確性を測る仕組み。 ## 重要な実体候補 - [[Steven Thurgood]] - [[David Ferguson]] - [[Betsy Beyer]] - [[Example Game Service]] ## 既存 SRE Book との関係 SRE Book 第 4 章は SLO の原則を説明する。本付録は、SRE Workbook 第 2 章「Implementing SLOs」と連動し、SLO を実際の文書に落とす形式を示す。既存の [[サービスレベル目標]] と [[エラーバジェット]] に具体例を補強できる。 ## 統合時に更新すべき既存ページ候補 - [[サービスレベル目標]]: SLO 文書の構成要素、複数カテゴリ SLO、ユーザー体験との相関未検証の明記を追記。 - [[エラーバジェット]]: 目標ごとの独立予算と具体計算例を追記。 - [[テレメトリ]]: SLI の測定点と測定不能領域の注意として低優先で接続可能。 ## 出典 - [[.raw/articles/sre-workbook-slo-document-2026-06-07.md]]