SRE
Site Reliability Engineering ・ エスアールイー
ソフトウェアエンジニアリングの手法で運用を設計する職能・方法論。Google発祥。
✦ 30秒で試す — 航海Googleは運用チームに「手作業は半分まで」と上限を課した1年後、新機能に使えた時間の合計が多いのは？予想してみる概要
SRE（Site Reliability Engineering、サイト信頼性エンジニアリング）は、サービスの運用をソフトウェアエンジニアリングの問題として解く方法論であり、それを実践する職能の名前でもあります。サーバの再起動やデプロイ作業を人手で繰り返すのではなく、「その作業をなくすソフトウェアを書く」ことを運用チームの本業に据える — この発想の転換が SRE の核心です。
発祥は Google です。2003年、Ben Treynor Sloss が「ソフトウェアエンジニアに運用を設計させたらどうなるか」という問いから立ち上げたチームが原型で、2016年に書籍『Site Reliability Engineering』（通称 SRE 本）としてその実践が公開されると、業界標準の語彙になりました。SLO による信頼性の数値目標、エラーバジェットによるリリース判断、ポストモーテムによる学習といった、現代の運用のベストプラクティスの多くはこの体系から出ています。
「SRE」という言葉は文脈によって、方法論そのもの、それを担う職種（SRE エンジニア）、その組織（SRE チーム）のいずれも指します。求人票の「SRE 募集」は職種の意味です。
なぜ生まれたか
伝統的な IT 組織では、開発（Dev）と運用（Ops）は別のチームでした。開発者はコードを書いて「壁の向こう」の運用チームに投げ、運用チームはそれを動かし続ける。この分業には2つの構造的な欠陥がありました。第一に、利害の対立です。開発は変更を出すほど評価され、運用は障害を防ぐほど評価されるため、変更＝リスクである以上、両者は必然的に衝突します。第二に、スケールしないことです。サービスが10倍に成長したとき、人手の運用作業も10倍になるなら、運用者を10倍雇い続けるしかありません。Google のような成長速度では、この線形なコスト増は最初から破綻していました。
SRE の答えは「運用者を増やす代わりに、運用をコードにする」でした。ソフトウェアエンジニアの素養を持つ人に運用を任せると、同じ作業を3回やらされた時点で自動化したくなる — この性質を組織設計に組み込んだのです。あわせて、開発との対立には SLO とエラーバジェットという数値の裁定者を導入し、「感情の綱引き」を「予算の管理」に置き換えました。
詳細
トイルの削減と50%ルール
SRE の実践の中心概念が「トイル（toil）」です。トイルとは、手作業で、繰り返しで、自動化可能で、サービスの成長に比例して増える運用作業を指します。手動デプロイ、定型的なアカウント発行、アラート対応での毎回同じ再起動などが典型です。トイルは緊急ではあっても資産を残さず、放置すればチームの時間を食い尽くします。
Google の SRE には「トイルは業務時間の50%まで」という運用ルールがあります。残りの50%以上を、トイルそのものを削減するエンジニアリング — 自動化、ツール開発、信頼性を高める設計変更 — に充てるのです。これにより、サービスが成長しても運用コストが線形には増えない構造を作ります。逆にトイルが50%を超え続けるチームは、開発チームに作業を差し戻すなどして強制的にバランスを回復させます。
なぜ「半分」も投資に回すのでしょうか。トイルはサービスの成長に比例して増えるので、手作業のままならサービスが10倍になればトイルも10倍になります。自動化の蓄えを毎週積み増してはじめて、成長の速さと相殺できます。投資を止めればトイルは再び増え始め、50%を越えたあたりから自動化を作る時間そのものが削られて、坂を転げ落ちるように燃え尽きます。上限を「ルール」として先に決めておくのは、この転落が始まってからでは自力で戻れないからです。
部品で確かめてください。週を進めるとサービスが育ち、手作業のトイル（朱の粒）が増えていきます。チームの時間の帯にある金の区切りを動かして、トイル以外の時間のうち何割を自動化に回すかを決めると、自動化の蓄えが粒を途中で吸い取るようになります。区切りを0%のまま走らせたときと、2〜3割を回したときとで、1年後のトイルと新機能に使えた時間を比べてみてください。
▶ で週を進めてください。チームの時間の帯にある金の区切りをつかむと、トイル以外の時間のうち何割を自動化に回すかを変えられます。
サービスは毎週5%育ち、自動化がない場合のトイルもそれに比例して増えます。自動化の効果は蓄えに応じて頭打ちになり、どうしても自動化できない手作業（5%）はサービスの規模とともに残ります。数値は仕組みを見るための模型です。
実践の道具立て — SLI から学習の文化まで
SRE の実践は一連の道具が連鎖して機能します。まずメトリクスからユーザー体験を映す SLI を選び、SLO として目標値を合意します。SLO の残量であるエラーバジェットがリリースの速度を裁き、予算の消費ペースに基づいてアラートを設計します。土台には監視と、システム内部の状態を問い合わせられる可観測性が要ります。
障害への備えも体系化されています。オンコールのローテーションを持続可能な負荷で設計し、インシデント対応には役割分担のある指揮体制を敷き、収束後はポストモーテムを書いて学習に変える。このとき「誰のミスか」を追及しない非難なき文化（blameless culture）を徹底するのが SRE の流儀です。人を罰すれば情報が隠れ、システムを直せば再発が減る — 障害を人の問題ではなくシステムの問題として扱う思想が、ここにも一貫しています。
日常の変更管理では、IaC によるインフラのコード化、CI/CD による自動デプロイ、カナリアリリースによる段階的展開が標準装備です。障害の大半は変更に起因するため、「変更を減らす」のではなく「変更を安全にする」方向に投資するのが SRE 的な解き方です。
DevOps との関係
SRE とよく比較されるのが DevOps です。DevOps は「開発と運用の分断をなくし、協調して速く安全に届けよう」という思想・文化運動であり、具体的な実装方法は規定していません。一方 SRE は、その理想を実現する具体的な仕組み — SLO、エラーバジェット、トイルの上限、ポストモーテム — を備えた実装体系です。Google 自身が「class SRE implements DevOps」（SRE は DevOps というインターフェースの一実装である）と表現しており、対立する概念ではなく抽象と具象の関係と捉えるのが正確です。
実務での落とし穴
SRE の導入でよくある失敗は、「運用チームの看板を SRE に掛け替えただけ」で中身が変わらないパターンです。SLO もエラーバジェットもなく、トイル削減の時間も確保されないまま名前だけ変えても、旧来の運用チームと同じ力学が続きます。逆に、Google の実践をそのまま輸入しようとする失敗もあります。数人のチームに専任 SRE 組織や厳密な50%ルールは過剰で、まずは主要サービスに SLO を1本立て、ポストモーテムを書き始める、といった段階的な導入が現実的です。SRE は制度や役職の名前である以前に、「運用の問題をソフトウェアで解けないか」と問い続ける姿勢だからです。
試問
サービスは毎週5%ずつ育ち、手作業の運用（トイル: 繰り返しで自動化できる手作業）もそれに比例して増えます。▶ で週が進み（1年 = 52週、約40秒）、チームの時間の帯にある金の区切りを左右にドラッグすると、トイル以外の時間のうち何割を自動化づくりに回すかを変えられます。残りの時間は新機能づくりに使われます。
▶ で週を進めてください。チームの時間の帯にある金の区切りをつかむと、トイル以外の時間のうち何割を自動化に回すかを変えられます。
サービスは毎週5%育ち、自動化がない場合のトイルもそれに比例して増えます。自動化の効果は蓄えに応じて頭打ちになり、どうしても自動化できない手作業（5%）はサービスの規模とともに残ります。数値は仕組みを見るための模型です。