SREとは？ ― 「信頼性」をエンジニアリングで実現する
SRE（Site Reliability Engineering：サイト信頼性エンジニアリング）とは、システムの信頼性（可用性・パフォーマンス・効率性）を、ソフトウェアエンジニアリングのアプローチで向上させる手法および職種のことです。
2003年頃にGoogle社のBen Treynor Sloss氏が提唱し、同社のサービス（Gmail、YouTube、Google検索など）を支えてきた実践に基づいています。「運用の仕事にソフトウェアエンジニアリングの手法を適用したもの」と定義されることが多いです。
SREが生まれた理由 ― 従来の運用の限界
従来のシステム運用チーム（Ops）は、手作業でサーバーの設定変更やデプロイ、障害対応を行っていました。しかし、サービスの規模が拡大するにつれて、手作業ベースの運用ではスケールしなくなります。
Googleは数百万台のサーバーを運用していますが、この規模では「1台1台を手で面倒を見る」ことは不可能です。そこで、運用業務そのものをコードで自動化し、繰り返し発生する手作業（トイル）を削減することで、少人数のチームでも大規模なシステムを安定運用できる体制を実現しました。これがSREです。
SREの核心 ― SLI / SLO / エラーバジェット
SREを実践するうえで中心となるのが、SLI・SLO・エラーバジェットという3つの概念です。
SLI（Service Level Indicator）
サービスの品質を測る具体的な指標です。たとえば「リクエストの99%が200ms以内に応答する」「エラー率が0.1%以下」などが典型的なSLIです。
SLO（Service Level Objective）
SLIに基づいて設定する目標値です。「月間稼働率99.9%（ダウンタイム月約43分まで許容）」のように定義します。重要なのは、100%を目標にしないことです。100%を目指すと開発の速度が極端に落ちるため、ビジネスが許容できるリスクのラインをSLOとして明示します。
エラーバジェット
SLOの「余裕分」を表す概念です。SLOが99.9%であれば、0.1%分（月43分）は「使っていいダウンタイム」と見なします。この予算が残っている間は新機能のリリースを積極的に行い、使い切りそうになったら安定性の改善に集中する――という意思決定の仕組みです。
エラーバジェットの画期的な点は、開発チームと運用チームの対立を数値で解消することにあります。「リリースしたい開発」と「変更を嫌がる運用」の間で、客観的な判断基準を提供するのです。
SREとDevOpsの違い
| 観点 | SRE | DevOps |
|---|---|---|
| 起源 | Google社の実践 | 業界全体のムーブメント |
| 焦点 | 信頼性の定量的な管理 | 開発と運用の文化的な融合 |
| アプローチ | SLI/SLO/エラーバジェットで科学的に判断 | CI/CD、自動化、コラボレーションの推進 |
| 役職 | SREエンジニアという明確な職種が存在 | DevOpsエンジニアは広義のロール |
Googleの元VP Ben Treynor Sloss氏は「SREはDevOpsの具体的な実装の一つ」と述べています。DevOpsが「何をすべきか（文化・原則）」を示すのに対し、SREは「どうやって実現するか（実践・指標）」を示しているとも言えます。
SREが日常的に取り組むこと
トイルの削減：SREは「手作業で繰り返し発生する運用タスク（トイル）」を50%以下に抑えることを目標とし、残りの時間をエンジニアリング（自動化や改善）に充てます。
ポストモーテム（事後検証）：障害発生後、原因と再発防止策を文書化します。重要なルールは「個人を責めない（Blameless）」こと。仕組みの改善にフォーカスします。
カオスエンジニアリング：意図的にシステムの一部を障害状態にし、全体が適切に回復できるかテストする手法。Netflixの「Chaos Monkey」が有名です。
よくある質問（FAQ）
Q. SREエンジニアになるには何が必要ですか？
A. インフラの知識（Linux、ネットワーク）に加えて、プログラミングスキル（Python、Goなど）が求められます。従来の運用エンジニアとの最大の違いは「コードを書いて運用を自動化する」点です。
Q. 小さなチームでもSREは実践できますか？
A. はい。SLI/SLOの設定とエラーバジェットの運用は、チームの規模に関係なく有効です。専任のSREチームが置けなくても、開発チーム内でSREの考え方を取り入れる「Embedded SRE」という形態もあります。
Q. SLOの「99.9%」と「99.99%」はどのくらい違いますか？
A. 月間で換算すると、99.9%は約43分のダウンタイムが許容されますが、99.99%では約4.3分しか許容されません。たった0.09%の差ですが、実現に必要なコストと労力は桁違いに増えます。
まとめ
SREは、Googleが実践してきた「信頼性をエンジニアリングで管理する」アプローチです。SLI/SLO/エラーバジェットという枠組みにより、開発速度と安定性のバランスを客観的な数値で判断できるようになります。DevOpsの理念を具体的な実践に落とし込んだものとして、大企業だけでなくスタートアップにも広がりを見せています。
コメント