📘 Site Reliability Engineering 第2章 要約：「サービスの信頼性を測る」徹底解説
✅ この章の目的：信頼性とは「測れる」もの
SREの基本的な考え方の1つに、「信頼性は感覚ではなく数値で語るべきである」という前提があります。
信頼性を“雰囲気”で語ることは運用や開発の意思決定を曖昧にし、エンジニア間やビジネスサイドとの誤解のもとになります。
本章では、SREが信頼性をどう定量的に定義し、測定し、運用に活かすかを、3つのキーワードで解説します：
- SLI（Service Level Indicator）
- SLO（Service Level Objective）
- SLA（Service Level Agreement）
📏 用語の定義と関係性
🔹 SLI：Service Level Indicator（サービス指標）
- 実際のサービス状態を表す定量的なメトリクス
- 例：リクエスト成功率、レスポンスのP95/P99レイテンシ、エラー率、スループットなど
- SLIの選定は、ユーザーの体験に直結する指標かどうかが最重要
🔸 SLO：Service Level Objective（サービス目標）
- SLIに基づく「内部向けの目標値」
- 通常は99.9%や95%といった可用性目標など
- ユーザーとの契約ではないが、運用ポリシーやリリース判断に使う基準
🟥 SLA：Service Level Agreement（サービス契約）
- 顧客（社外）と結ぶ正式な契約。違反時はペナルティが発生する可能性もある。
- 通常、SLOよりやや緩めに設定される。
🔁 関係性：SLI（実測値）→ SLO（内部目標）→ SLA（契約）
🧪 SLIの具体例
| 指標カテゴリ | 例 |
|---|---|
| 可用性 | 成功レスポンスの割合（HTTP 2xx/3xx） |
| レイテンシ | P95/P99の応答時間 |
| 正確性 | コンテンツの誤り率、同期ズレ発生率 |
| スループット | 処理件数、リクエスト数 |
| フレッシュネス | データが最新である割合（キャッシュ、レポート等） |
✅ 重要な観点：「ブラックボックス vs ホワイトボックス」
- ブラックボックス監視：ユーザーの視点から見たシステムの結果（例：curlでの死活監視）
- ホワイトボックス監視：内部メトリクス（例：gRPCのエラーレート、DBクエリ失敗数など）
🎯 SLOが必要な理由：妥当な信頼性のゴールを定める
SLOを設定することで、以下のような組織的判断が可能になります：
- 信頼性に問題があるかどうかを定量的に判断できる
- アラートの正当性を評価できる（ノイズの排除）
- 機能リリース vs 安定運用のトレードオフ判断の基準になる
SLOは「何が正常か？」という合意形成の出発点でもあります。
📉 アラート設計の誤りと、SLOに基づく改善
❌ よくある誤り
- CPU使用率80%を超えたらアラート
- ディスク使用率が90%超でエスカレーション
これらはシステムの状態を監視しているだけで、ユーザー影響を直接反映していません。
✅ SRE的な設計
- 「HTTP 5xxが10%超過」など、SLO違反と連動したアラート
- 「ユーザーに影響を与えるメトリクスに基づく通知」が重要
アラートは“夜中に起きる価値がある”イベントかどうかで精査するべきです。
💡 実務での導入ステップ（SLI/SLO）
- 現状モニタリングしている項目をリストアップする
- ユーザー影響に直結する項目だけをSLI候補として残す
- 現状の数値分布（成功率、P99レイテンシ）を確認する
- SLOを仮設定し、しばらく様子を見る（例：可用性99.9%）
- アラートポリシーをSLOベースにリファクタリングする
🔚 まとめ：信頼性を“感覚”から“設計対象”へ
この章で得られる最大の学びは、以下のように整理できます：
- ✅ 信頼性は「測れる指標」に落とし込んで初めて議論できる
- ✅ SLI → SLO → SLAという階層で管理し、役割を分ける
- ✅ SLOをもとにアラート・運用判断・リリース管理を設計する
- ✅ チームにとっての「十分に良い信頼性（Good Enough）」を定義するのが第一歩
次章（第3章）では、実際に「良いSLIとは何か？」「SLOをどう設計するのか？」という設計論に踏み込みます。