フレームワーク活用ガイドひとことで言うと#
「運用はソフトウェアの問題である」という思想のもと、SLI/SLO/エラーバジェットを中核に据えて信頼性を定量的に管理し、トイル（手作業）を自動化で減らしていくGoogleの運用哲学。
押さえておきたい用語#
- SLI（Service Level Indicator）
- サービスの信頼性を測る**具体的なメトリクス（指標）**を指す。レイテンシ、可用性、スループットなど「ユーザー体験を最も正確に反映する数値」を選ぶ。
- SLO（Service Level Objective）
- SLIに対して設定する目標値のこと。例えば「月間可用性99.9%」。ビジネスが許容できる最低ラインを反映した現実的な目標。
- エラーバジェット（Error Budget）
- SLOの余白を**「使える信頼性の予算」として管理する**仕組みのこと。例えば可用性SLO 99.9%なら月間43分のダウンタイムが「予算」。
- トイル（Toil）
- 手動で繰り返し行う、自動化可能だが長期的な価値がない運用作業のこと。SREではトイルに費やす時間を50%以下に抑えることを目指す。
- ポストモーテム（Postmortem）
- 障害後に実施する根本原因分析と再発防止策の振り返りである。「誰が悪いか」ではなく「何がシステム的に改善できるか」に焦点を当てる非難なき文化が前提。
SRE原則の全体像#
こんな悩みに効く#
- 「可用性99.99%を目指す」と言いつつ、具体的にどう計測・管理すればいいかわからない
- 運用チームが手作業（トイル）に追われ、改善の時間が取れない
- 開発チームと運用チームが対立し、リリースのたびに揉める
基本の使い方#
サービスの信頼性を測る具体的な指標を決める。
- レイテンシ: リクエストの95パーセンタイル応答時間
- 可用性: 成功したリクエストの割合
- スループット: 単位時間あたりの処理数
- ユーザーに最も影響するメトリクスを選ぶ
ポイント: SLIは「ユーザーの体験を最も正確に反映する指標」を選ぶ。
SLIに対する目標値を決める。
- 例: 「月間可用性 99.9%（ダウンタイム約43分/月）」
- 100%を目標にしない。完璧は現実的でなくコストも膨大
- ビジネスの要件とエンジニアリングのコストのバランスで決める
ポイント: SLOは「ビジネスが許容できる最低ライン」を反映した現実的な目標。
SLOの余白を**「使える信頼性の予算」**として管理する。
- 可用性SLO 99.9% → 月間43分のダウンタイムが「予算」
- エラーバジェットが残っている → 新機能リリースやリスクのある変更を許可
- エラーバジェットが枯渇 → リリースを凍結し、信頼性改善に集中
ポイント: エラーバジェットが開発チームと運用チームの共通言語になる。
手作業で繰り返し行っている運用作業を特定し、自動化する。
- トイルの定義: 手動、繰り返し、自動化可能、戦術的、長期的な価値がない
- トイルに費やす時間を50%以下に抑える（残りはエンジニアリングに使う）
- 自動化の投資対効果が高いものから着手する
ポイント: トイルを減らした分だけ、プロアクティブな信頼性改善に時間を使える。
具体例#
状況: 従業員50名、顧客企業200社のBtoB SaaS。エンジニア15名のうち3名が「運用担当」として障害対応とデプロイに追われ、改善の時間がゼロだった。月間障害件数は平均4.5回。
SLI定義: APIのレスポンスタイム p99 と、HTTPステータス 2xx の割合を主要SLIに設定。
SLO設定: 月間可用性 99.95%（ダウンタイム約22分/月）、p99レイテンシ < 500ms。
エラーバジェット運用: 月初にエラーバジェット22分からスタート。月半ばのデプロイで5分間の障害が発生 → 残り17分。まだ余裕があるのでリリースは継続。月末にさらに15分の障害 → 残り2分。翌月はリリース凍結とし、信頼性改善スプリントを実施。
トイル削減: 毎週3時間かかっていた「証明書の手動更新」をcert-managerで自動化。年間156時間を削減。
| 指標 | Before | After（6ヶ月後） |
|---|---|---|
| 月間障害件数 | 4.5回 | 1.2回 |
| トイル比率 | 運用チームの75% | 35% |
| エンジニアリング投資時間 | 週10時間 | 週32時間 |
障害月4.5回→1.2回、エンジニアリング投資時間は週10時間→32時間。SLI/SLOで「信頼性を数字で会話する」文化が定着したことで、開発と運用の対立が消えた。
状況: MAU 150万人の動画配信サービス。開発チームは「毎週リリースしたい」、運用チームは「障害が怖いからリリースを減らしたい」で常に対立。リリース頻度は月1回に抑えられていたが、機能リリースが遅れてビジネス側からの不満が増大。
エラーバジェットの導入:
- SLO: 月間可用性 99.9%（約43分/月のダウンタイム許容）
- エラーバジェット: 月43分
- ルール: バジェット残50%以上 → 週次リリースOK / 残25%以下 → 隔週 / 枯渇 → 凍結
| 指標 | Before | After |
|---|---|---|
| リリース頻度 | 月1回 | 週1.8回（月平均） |
| リリース起因障害 | 月2.1回 | 月0.8回 |
| 機能リリース速度 | 企画から平均8週間 | 企画から平均3週間 |
| 開発-運用間の対立 | 週1回以上の議論 | エラーバジェットで定量判断 |
リリース頻度月1回→週1.8回、障害は62%削減。「感情ではなく数字で判断する」共通言語ができたことが、この両立を可能にした。
状況: 口座数45万の地方銀行。IT部門15名のうち運用担当5名が、日次バッチ監視・ログ確認・手動レポート作成に1日の65%を費やしていた。月末は残業が常態化し、ヒューマンエラーによる障害が年間8件発生。
トイルの洗い出しと自動化:
| トイル | 週あたり時間 | 自動化手段 | 削減後 |
|---|---|---|---|
| 日次バッチ監視 | 10時間 | Datadogアラート | 1時間 |
| ログ目視確認 | 8時間 | ログ解析+異常検知 | 0.5時間 |
| 月次レポート作成 | 6時間 | Grafanaダッシュボード | 0.5時間 |
| 証明書更新 | 2時間/月 | cert-manager | 0時間 |
| 手動デプロイ | 4時間 | CI/CDパイプライン | 0.5時間 |
| 指標 | Before | After |
|---|---|---|
| トイル比率 | 65% | 22% |
| ヒューマンエラー障害 | 年間8件 | 年間1件 |
| 月末残業時間 | 平均30時間/人 | 平均5時間/人 |
| 改善プロジェクトへの投資 | 月10時間 | 月80時間 |
トイル比率65%→22%、ヒューマンエラー障害87%削減、改善投資時間8倍。銀行のような保守的な組織でも、数字で効果を示せば自動化投資の承認は得られる。
やりがちな失敗パターン#
- SLOを100%に設定する — 100%を目指すとすべての変更がリスクになり、何もリリースできなくなる。ビジネスに必要十分な目標値を設定すること
- エラーバジェットのルールを曖昧にする — 「バジェットが尽きたらリリース凍結」のルールが形骸化し、結局なし崩しにリリースされる。エラーバジェットポリシーを明文化し、ステークホルダーと合意すること
- トイル削減を後回しにする — 目の前のインシデント対応に追われ、自動化に投資する時間が取れない悪循環に陥る。トイル削減のための時間を明示的にスプリントに確保すること
- SLIをエンジニア目線だけで選ぶ — CPU使用率やメモリ使用率をSLIにしてしまい、ユーザー体験と乖離する。SLIはユーザーが感じる品質（レイテンシ、可用性）を直接測る指標にすること
企業での実践例 — Google#
SREはGoogleのエンジニアリング担当VP、ベン・トレイナー・スロスが2003年に立ち上げたチームから始まった。当時のGoogleは急成長に伴いサービス障害が増加しており、「運用を人手で回す」モデルの限界に直面していた。スロスは「運用の問題をソフトウェアエンジニアリングで解決する」というアプローチでSREチームを編成し、SLI/SLO/エラーバジェットという信頼性の定量管理体系を確立した。
Googleでは現在、SREチームが数千人規模で稼働しており、Gmail、YouTube、Google Cloud、Google検索など数十億人が利用するサービスの信頼性を支えている。SREの原則のもと、チームの作業時間の50%以上をエンジニアリング（自動化・ツール開発・アーキテクチャ改善）に充てるルールが徹底されており、トイル（手作業の運用）が50%を超えたチームは自動化への投資を優先する方針が全社的に適用されている。2016年にGoogleがO’Reillyから無償公開した『Site Reliability Engineering』は、社内で10年以上かけて蓄積された実践知をまとめたもので、業界全体にSREの考え方を広めるきっかけとなった。Netflix、LinkedIn、Dropboxなど多くのテック企業がGoogleのSREモデルを参考に自社の運用体制を構築している。
まとめ#
SRE原則は 「信頼性をエンジニアリングの問題として扱う」 ためのフレームワーク。SLI/SLO/エラーバジェットで信頼性を定量化し、トイルの削減で改善の時間を確保する。完璧を目指すのではなく 「ビジネスに必要十分な信頼性」 を合理的に管理することが本質。