SRE

概要

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%を超え続けるチームは、開発チームに作業を差し戻すなどして強制的にバランスを回復させます。

実践の道具立て — 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 は制度や役職の名前である以前に、「運用の問題をソフトウェアで解けないか」と問い続ける姿勢だからです。