> [!abstract] 概要 > Chris Jones、[[John Wilkes]]、[[Niall Murphy]]、Cody Smith による章。SLI/SLO/SLA のフレームワークを定義し、サービス種別ごとの指標選定指針とエラーバジェットの運用を体系化する。 ## 書誌情報 - 書名: Site Reliability Engineering: How Google Runs Production Systems - 章: Chapter 4 — Service Level Objectives - 著者: Chris Jones, [[John Wilkes]], [[Niall Murphy]], Cody Smith - 出版: O'Reilly Media, 2016 年 4 月 ## SLI/SLO/SLA フレームワーク ### SLI（Service Level Indicator） SLI はサービスの振る舞いを定量的に計測する指標である。リクエストレイテンシ、エラー率、スループット、可用性などが典型例にあたる。SLI はサービスの健全性を直接的に反映する**計測値**であり、目標値ではない。 ### SLO（Service Level Objective） SLO は SLI の目標値あるいは許容範囲である。「SLI $\leq$ target」の形をとる。例: 「リクエストレイテンシの p99 が 200ms 以下」。SLO はサービスの信頼性に関する内部的な目標であり、外部への約束ではない。 ### SLA（Service Level Agreement） SLA は SLO に**違反時の罰則（consequences）**を付加した明示的な契約である。SLO が達成されなかった場合のクレジットバック、返金、その他のペナルティを含む。SLA は通常、外部顧客との間で締結される。 SLI → SLO → SLA は抽象度が上がる方向の階層をなし、SLI なしに SLO は定義できず、SLO なしに SLA は意味を持たない。 ## パーセンタイルの重視 レイテンシ指標を**平均値**で評価してはならない。平均はテールレイテンシ（遅い上位数%）の情報を潰す。少数のユーザーが極端に悪い体験をしている状況を平均は隠蔽する。 推奨される計測はパーセンタイルであり、特に以下が重視される。 - **p50（中央値）**: 典型的なユーザー体験 - **p99**: テールレイテンシの大部分 - **p99.9**: 最も影響を受けるユーザーの体験 ## サービス種別ごとの優先指標 | サービス種別 | 優先 SLI | |---|---| | ユーザー向けサービス | 可用性（availability）、レイテンシ（latency）、スループット | | ストレージシステム | 耐久性（durability）、可用性、レイテンシ | | ビッグデータパイプライン | スループット、エンドツーエンドレイテンシ | ストレージシステムでは、データの**耐久性**が最も根本的な指標である。データを失うことはサービス停止よりも深刻であり、回復不能となる場合がある。 ## エラーバジェットと停滞防止 [[エラーバジェット]]は SLO の副産物である。SLO が 99.9% であれば、四半期の 0.1% 分が「使える障害量」となる。このバジェットが存在しないと、以下の停滞が生じる。 - **SRE 側**: リスクのある変更を一切拒否する保守主義に陥る - **プロダクト側**: SRE の反対を回避するため、変更を隠蔽または小分けにする非生産的な行動を取る エラーバジェットは双方に「使ってよいリスク量」を明示し、定量的な意思決定を可能にする。バジェットが残っていればリリースを加速し、枯渇すれば信頼性改善に集中する——この動的な切り替えが停滞を防止する。 ## 位置づけ 本章で確立された SLI/SLO/SLA フレームワークは、後続の研究（[[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds|Nines are Not Enough]]、[[@2020__NSDI__Meaningful Availability|Meaningful Availability]]）で有意義性・比例性・実用性の観点から精緻化されている。しかし基本構造——計測指標と目標値の分離、パーセンタイルの重視、エラーバジェットによるインセンティブ設計——は 10 年後の現在も変わらない。