SRE と DevOps の違い — 重なる場所と分かれる場所
求人票には DevOps エンジニアと SRE が別々に載っているのに、業務の説明は半分ほど重なっています。同じものの別名でしょうか、別の職種でしょうか? 答えを先に書くと、DevOps は開発と運用の壁をなくそうという文化・方法論で、SRE はその問題をソフトウェアエンジニアリングで解く具体的な実装です。グーグルの表現を借りれば「SRE は DevOps というインターフェイスの一実装(class SRE implements DevOps)」です。この記事はこの一行を実務の感覚に展開します。SRE 入門 4 部作の第 1 回で、続けて SLI・SLO・SLA、エラーバジェット、インシデントハンドリングを扱います。
DevOps — 壁をなくそうという方向の宣言 #
DevOps は特定の職種である前に方向です。開発チームは速く変えたく、運用チームは変わらないほうが安定するので、互いを壁の向こうへ投げ合っていた(「作ったから、そっちで動かして」)構造をなくそうというものです。実践項目はデプロイの自動化(CI/CD)、インフラのコード化(IaC)、観測とフィードバックループ、小さい単位の頻繁なリリースのように、道具より流れに関するものです。
方向の宣言なので組織ごとに解釈が違い、だから「DevOps エンジニア」という肩書きの実体も組織ごとに違います。ある場所では CI/CD と IaC を作るビルド・プラットフォームエンジニアで、ある場所では名前だけ変わったシステム管理者です。
SRE — 信頼性を数字で扱うエンジニアリング #
SRE(Site Reliability Engineering)はグーグルが作った職種であり方法論で、出発点が明確です。運用の問題を、運用者ではなくソフトウェアエンジニアに解かせたらどうなるかです。その結果が SRE 固有の道具です。
- 信頼性の定量化 — 「安定的に」という形容詞を、SLI(指標)と SLO(目標)という数字に変えます。可用性 99.9% のように目標が数字なら、いま目標を守れているかは論争ではなく照会になります。
- エラーバジェット — 100% は目標ではないという宣言です。SLO が 99.9% なら 0.1% 分の失敗は使える予算で、予算が残っていれば速くデプロイし、使い切ったら信頼性の作業が優先権を持ちます。開発速度と安定性の対立を、交渉ではなくルールに変える装置です。
- トイル(toil)の上限 — 反復的・手作業の運用作業をトイルと呼び、業務時間の一定割合(グーグル基準で 50%)を超えないように管理します。あふれたら自動化が最優先の業務になります。「運用を自動化することに使う時間」が職務定義に入っているわけです。
- 非難のないポストモーテム — 障害を人の過ちではなくシステムの欠陥として扱い、再発防止を構造として作ります。
整理すると、DevOps が「開発のように運用しよう」という方向なら、SRE はその方向を数字(SLO)、予算(エラーバジェット)、上限(トイル)、手順(ポストモーテム)という運用可能なルールに落とし込んだものです。
実務で分かれる形 #
共通部分は大きいのです。どちらも自動化、IaC、CI/CD、観測を使います。分かれるのは責任の焦点です。
| 観点 | DevOps エンジニア(通称) | SRE |
|---|---|---|
| 焦点 | 開発 → デプロイの流れを速く滑らかに | サービスが目標の信頼性を守るように |
| 代表的な成果物 | CI/CD パイプライン、IaC、開発者セルフサービス | SLO の定義、ダッシュボード・アラート体系、ポストモーテム、容量計画 |
| 成功指標 | デプロイ頻度、リードタイム、開発者体験 | SLO 達成率、バジェット消費速度、トイル比率、MTTR |
| 障害時 | パイプライン・インフラの復旧支援 | インシデントの指揮、原因分析、再発防止の設計 |
小さい組織では一人が両方をやります。規模が大きくなると、デプロイ・開発者体験の側はプラットフォームエンジニアリングという名前で、信頼性・オンコールの側は SRE という名前で分化するのが近年の一般的な形です。求人票を読むときも、肩書きより成功指標がデプロイ速度側か信頼性側かを見れば実体が見えます。
どちらが必要か — 組織の観点の判断 #
導入の順序を問う組織への実用的な答えはこうです。
- デプロイが苦しいなら(手作業のデプロイ、環境の不一致、リリースがイベント)、まず必要なのは DevOps の実践、つまりパイプラインと IaC です。
- デプロイは回るのに障害が繰り返され、安定性と速度が毎回会議室で争うなら、SRE の道具が必要な時点です。そのとき最初の一歩は採用ではなく SLO を定義することです。次回扱う SLI・SLO・SLA がその出発点です。
- 順序をひっくり返すと(測定のない SRE の肩書き、パイプラインのないエラーバジェット)名前だけが残ります。SRE の道具はすべて測定の上に立っているからです。
まとめ #
- DevOps は開発と運用の壁をなくそうという文化・方法論で、SRE はそれをソフトウェアエンジニアリングと数字で実装した方法です。
- SRE 固有の装置は SLI/SLO、エラーバジェット、トイルの上限、非難のないポストモーテムです。共通の道具(CI/CD、IaC)は両方が使います。
- 実務では成功指標が分かれ道です。デプロイ速度・開発者体験なら DevOps/プラットフォーム、SLO 達成・MTTR なら SRE です。
- デプロイに苦労している組織は DevOps の実践から、安定性の対立が繰り返される組織は SLO の定義から始めます。
- SRE 導入の最初の一歩は採用ではなく測定です。次回(SLI・SLO・SLA)がその具体的な方法です。