SRE と SLO / SLI
信頼性を「気合い」ではなく「数字」で運用する考え方。SLI(測る)→SLO(目標)→エラーバジェット(落ちてよい量)で、開発速度と安定性のバランスを決める。
- 1.SRE は Google 発の運用手法。信頼性を“工学（数字とルール）”として扱う。
- 2.SLI(実測の指標)→SLO(自分たちの目標)→SLA(顧客との契約)の順に厳しくなる。
- 3.エラーバジェット＝(100% − SLO)。残っていれば攻め、使い切れば守る、を機械的に判断する。
SRE とは：「信頼性」を工学にする
SRE は Google が提唱した運用手法で、ひとことで言えば 「運用の問題をソフトウェアエンジニアリングで解く」 アプローチです。従来の運用（手作業で監視し、落ちたら駆けつける）に対して、SRE は次のような立場を取ります。
- 信頼性は 測定できる（＝数字で語る）
- 信頼性に 目標値 を決める（高すぎても低すぎてもダメ）
- 手作業の繰り返し（後述のトイル）は コードで自動化 して減らす
重要なのは 「信頼性 100% は目標にしない」 という発想です。100% に近づけるほどコストは指数関数的に増え、しかもユーザーは回線やデバイス側の問題で、もとから 100% を体感できません。だから「ユーザーが不満を持たない十分なライン」を決め、そこまでで止める。残った余力は、新機能の開発や挑戦に回します。
SLI / SLO / SLA：3つの「サービスレベル」
名前が似ていて混同しがちですが、何を・誰に対して 言うかが違います。
| 用語 | 正式名 | 何か | 誰のため |
|---|---|---|---|
| SLI | Indicator（指標） | 実測した“今の良さ”の数値 | 計測・観測のため |
| SLO | Objective（目標） | 自分たちで決める内部目標 | チームの意思決定のため |
| SLA | Agreement（契約） | 顧客と結ぶ約束＋違反時の補償 | 対外的な契約のため |
SLI：まず「測る」
SLI（Service Level Indicator） は、サービスの良さを表す 実測値 です。多くは「良かったリクエスト ÷ 全リクエスト」の比率で表します。
- 可用性：成功した応答 ÷ 全応答（例：99.95%）
- レイテンシ：300ms 以内に返せた応答の割合（例：99%）
- エラー率：5xx を返した割合
- 品質/鮮度：データが古すぎないか、欠損していないか
CPU 使用率やメモリは SLI には向きません。ユーザーが体感する良し悪し（つながる・速い・正しい）に直結する指標を選ぶのがコツ。CPU はそれを説明する補助メトリクスとして観測します。SLI とメトリクス全般の違いは オブザーバビリティ も参照。
SLO：自分たちで決める「目標」
SLO（Service Level Objective） は、SLI が どのくらいの値であるべきか という目標です。「直近30日で可用性 99.9% 以上」のように、必ず 期間 とセットで決めます。
- SLO はあくまで 内部目標（チームが守りたいライン）
- 高ければ良いわけではない。99.9%（月43分ダウン）か 99.99%（月4.3分）か で、必要なコストも体制もまるで違う
- 「9 の数」（ナイン）でよく語られます
| SLO | 月あたり許容ダウン | 年あたり許容ダウン |
|---|---|---|
| 99%（ツーナイン） | 約 7.2 時間 | 約 3.65 日 |
| 99.9%（スリーナイン） | 約 43 分 | 約 8.76 時間 |
| 99.99%（フォーナイン） | 約 4.3 分 | 約 52.6 分 |
SLA：顧客との「契約」
SLA（Service Level Agreement） は、顧客と結ぶ 契約上の約束 で、破ると 返金やクレジット などのペナルティが発生します。だから SLA は SLO より必ず緩く 設定します（例：社内 SLO 99.95% に対し、対外 SLA は 99.9%）。先にチーム内で警報が鳴る“余白”を作っておくわけです。
SLA を SLO と同じ厳しさにすると、内部目標を割った瞬間に契約違反＝賠償になります。SLA は「これを下回ったら補償します」という 最低保証ライン。普段の運用目標（SLO）はその一段上に置くのが鉄則です。
エラーバジェット：開発速度と信頼性のバランス装置
SRE の核心が エラーバジェット（error budget） です。定義はシンプルで、
エラーバジェット = 100% − SLO
SLO が 99.9% なら、エラーバジェットは 0.1%。これは「この期間に、ここまでは落ちて（失敗して）よい」という 許容枠 です。30日なら約43分ぶんの“失敗してよい時間”が予算として配られます。
この予算をどう使うかで、チームの行動が 自動的に 決まります。
| 状態 | 意味 | とるべき行動 |
|---|---|---|
| 予算が残っている | まだ落ちる余裕がある | 新機能をどんどん出す・攻めたリリースOK |
| 予算を使い切った | 今期はもう落とせない | 機能開発を止め、信頼性向上・修正に専念 |
ここが SRE の発明です。「もっと速く出したい開発チーム」と「安定させたい運用チーム」は普段対立しますが、エラーバジェットという 共通の数字 があれば、「予算が残っているか？」だけで議論が決着します。感情論ではなく、残高で決める。
エラーバジェットを 使い切れずに大量に余らせる のは、実は「遅すぎる・慎重すぎる」サイン。予算は使ってこそ価値が出る（＝その範囲でリスクを取り、開発を速める）リソースだと考えます。「無事故＝満点」ではありません。
エラーバジェットは デプロイ戦略 とも直結します。予算に余裕があるならカナリアの比率を上げて速く展開し、残り少なければ慎重なロールアウトに切り替える、といった判断材料になります。
トイル削減：手作業を「予算」とみなす
SRE のもう一つの柱が トイル（toil） の削減です。トイルとは、
- 手作業で、繰り返しで、自動化できるのに人がやっていて、
- サービスが大きくなると 比例して増える（＝スケールしない）
ような“作業のための作業”を指します。例：手動デプロイ、手動でのログ確認、定型的な再起動、毎回同じ手順の障害対応。
SRE では「業務時間のうち トイルは 50% 未満 に抑え、残りを自動化やツール開発に充てる」という目安を置きます。トイルを IaC や CI/CD、自動復旧スクリプトで潰していくことで、人は「同じ作業の繰り返し」から解放され、より価値の高い改善に時間を使えるようになります。
すべての異常で人を叩き起こすと、本当に重要な通知が埋もれます（アラート疲れ）。SLO を脅かす（エラーバジェットを急速に消費する）事象だけ をページング対象にするのが SRE 流。「CPU が高い」ではなく「このままだと SLO を割る」で鳴らします。
まとめ：数字で運用する
- SLI で測り、SLO で目標を決め、SLA で顧客に約束する（右にいくほど緩く）
- エラーバジェット = 100% − SLO。残高で「攻める／守る」を機械的に判断
- 100% は目指さない。余白（予算）はリスクを取って開発を速めるための原資
- トイルを自動化で減らし、人を繰り返し作業から解放する
SRE は特別なツールの名前ではなく、「信頼性を数字とルールで扱う」という運用の文化 です。まず自分たちのサービスの SLI を1つ選び、SLO を決めるところから始められます。
DevOps/インフラ Article
SRE と SLO / SLIを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
SRE
比較で見る軸
難易度: intermediate / カテゴリ: DevOps/インフラ / タグ数: 4
導入後に効く点
SLI(実測の指標)→SLO(自分たちの目標)→SLA(顧客との契約)の順に厳しくなる。
先に潰すリスク
用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。
- 難易度
- intermediate
- カテゴリ
- DevOps/インフラ
- タグ数
- 4
判断チェックリスト
- 自社の用途が「SRE / SLO」に近いか確認する。
- 強みである「SRE は Google 発の運用手法。信頼性を“工学（数字とルール）”として扱う。」が本当に評価軸になるか確認する。
- 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。