SREとは・SLI/SLO/エラーバジェット

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：監視とアラート設計　|　関連：インシデント対応とポストモーテム・DevOps文化とDORA 4指標

要点（BLUF）

SRE＝信頼性をエンジニアリングの対象として扱う営み（Google発祥）。運用を「人海戦術」でなく「ソフトウェアの問題」として解く。
信頼性を数値化する3点セット：SLI（測る指標：可用性・レイテンシ等）、SLO（目標値：例 99.9%）、エラーバジェット（許容する失敗量＝100%−SLO）。
100%は目指さない。エラーバジェットが残っていれば速く出す、使い切ったら安定化に振る。速度と信頼性を予算で調停する。

概念 ── 信頼性は「機能」

従来、開発は「速く出したい」、運用は「壊したくない」で対立しました。SREはこれを**共通の数値（エラーバジェット）**で調停します。考え方の中心は「信頼性は高ければ良いのではなく、ちょうどよい水準がある」。100%可用性は不可能で、目指すほどコストが指数的に増え、機能開発が止まります。

flowchart LR
    sli["SLI（測る）：成功した割合・速さ"] --> slo["SLO（目標）：例 99.9%にする"]
    slo --> budget["エラーバジェット：残り0.1%は失敗してよい"]
    budget -->|"残あり"| ship["速く新機能を出す"]
    budget -->|"使い切り"| stable["リリースを止め安定化に注力"]

仕組み ── SLI・SLO・エラーバジェット

SLI（Service Level Indicator）＝サービスの良さを測る実測値。代表例：

可用性：成功リクエスト ÷ 全リクエスト
レイテンシ：95/99パーセンタイルの応答時間
これらは7章のメトリクス（メトリクス・ログ・トレース（3本柱））がそのまま材料。

SLO（Service Level Objective）＝SLIに対する目標値。「直近28日で可用性99.9%」のように期間付きで決める。ユーザーが満足する最低ラインを狙う（高すぎず低すぎず）。

エラーバジェット＝100% − SLO ＝ 許容される失敗の総量。SLO 99.9% なら 0.1% は失敗してよい。リクエストが月100万なら約1000回までの失敗が予算内。

flowchart TB
    total["全リクエスト（月100万）"] --> ok["成功 99.9%（999,000）"]
    total --> budget["エラーバジェット 0.1%（約1,000回まで許容）"]
    budget -->|"消費が早い"| halt["新規リリース凍結（07-02 のバーンレート）"]
    budget -->|"余裕あり"| release["積極的にリリース"]

SLA（Service Level Agreement）と混同しない。SLAは顧客との契約（破ると返金等のペナルティ）。SLOは社内の目標で、通常 SLA より厳しく設定し、余裕を持って SLA を守る。

なぜエラーバジェットなのか

対立を数値で解くため：「もっと速く」対「もっと安定」を、感情でなく残予算で判断する。予算があれば攻め、無ければ守る。明快なルール。
100%の罠を避けるため：信頼性を上げ過ぎると、機能開発が止まりコストが爆発する。ユーザーは99.9%と99.99%の差を体感しないことも多い。過剰な信頼性は無駄。
トイルを減らすため：SREは反復的な手作業（toil）を50%以下に抑え、残りを自動化・改善に使うのが定石。自己修復（スケーリングと自己修復）や IaC（IaCとは・宣言的構成）はトイル削減そのもの。

⚠️ よくある誤解・落とし穴

「SLOは高いほど良い」→ 高すぎる SLO はコスト爆発と開発停止を招く。ユーザー満足の最低ラインを狙う。
「SLIを内部指標（CPU等）で決める」→ ユーザー体感とずれる。ユーザー視点の成功率・速さで測る（症状ベース＝監視とアラート設計）。
「エラーバジェットを使い切っても出し続ける」→ 予算超過時はリリースを止め安定化に振るのがルール。守らないと数値が形骸化。
「SLA と SLO を同一視」→ SLA は契約・ペナルティ、SLO は社内目標。SLO は SLA より厳しく。
「全サービスに同じSLO」→ 重要度で変える。決済は厳しく、社内バッチは緩く。リソースを重要度に配分。

対応ラボ

なし（概念トピック）。SLI の材料となるメトリクス収集はメトリクス・ログ・トレース（3本柱）のラボで。SLO/バーンレートのアラートは Prometheus を拡張して実装（要最新確認）。