// シス担のミカタ
運用・監視

SRE（サイトリライアビリティエンジニアリング） えすあーるいー・さいとりらいあびりてぃえんじにありんぐ

サイトリライアビリティSLOエラーバジェットToil削減GoogleDevOps
SREって何？インフラエンジニアとどう違うの？

簡単に言うとこんな感じ！

SREはGoogleが作った「信頼性をエンジニアリングで解決する役割」のことだよ。従来の運用担当が「手作業で監視・対応」していたのに対して、SREは「自動化・コード・データで信頼性を向上させる」ソフトウェアエンジニア的アプローチを取るんだ。「運用を工学的に解決するエンジニア」って感じかな！

SRE（Site Reliability Engineering）とは

SRE（Site Reliability Engineering：サイトリライアビリティエンジニアリング）とは、ソフトウェアエンジニアリングの手法をシステムの信頼性・可用性・運用の問題に適用するアプローチであり、そのアプローチを実践するエンジニアの職種でもあります。2003年にGoogleのBen Treynorが提唱・実践し、2016年にGoogle SRE Bookの公開により業界全体に広まりました。

SREの核心は「信頼性とリリース速度のトレードオフを数値（SLO・エラーバジェット）で管理する」ことです。全ての時間をインシデント対応に使うのではなく、時間の50%以上を自動化・改善・工学的解決に使うことを目標とします。手作業で繰り返す単純な運用作業をToil（トイル）と呼び、Toilを削減して高付加価値な業務に注力します。

DevOpsとの関係では、DevOpsが開発と運用の文化的融合を指すのに対し、SREはその具体的な実装方法の一つです。SREを採用している組織では、SREチームが本番環境への変更権限を持つ代わりに、開発チームに信頼性の基準を課します。

SREの主要コンセプト

コンセプト説明
SLI / SLO / SLA信頼性を測定・目標設定・契約する3層構造（詳細は「メトリクス・SLO」参照）
エラーバジェットSLOまでの余裕（許容できる障害時間）。リリース可否の判断基準
Toil手作業で繰り返す定型作業。SREはToilを50%以下に抑えることを目標とする
オンコール本番障害に24時間対応する当番制度。Alert設計とエスカレーションが重要
ポストモーテム障害後の振り返り。「犯人探しではなく学習」のBlame-lessな文化が重要
キャパシティプランニング将来のトラフィック増加を予測し、インフラを事前に拡張する設計

歴史と背景

  • 2003年：GoogleのBen TreynorがSREチームを設立。ソフトウェアエンジニアに運用業務を担わせる新しい役割モデルを確立
  • 2016年：Google SRE Book（「Site Reliability Engineering」）がO’Reillyから出版・無料公開。業界への普及が加速
  • 2018年：「The Site Reliability Workbook」公開。SREの実践的な導入方法が整理される
  • 2018年〜：Netflix・Amazon・Facebook等の大手テック企業がSRE組織を整備。ジョブ市場での需要が急増
  • 2020年〜：中規模企業でもSREまたはSREプラクティスを部分的に採用する動きが広まる
  • 2022年〜：Platform Engineeringの台頭。SREの知見を活かした「開発者向け内部プラットフォーム」の構築が注目される

SREの責任領域と他ロールとの関係

SREの責任領域と関連チームとの関係 SREチーム 信頼性 × エンジニアリング 開発チーム 機能開発・速度 エラーバジェット消費 インフラ/クラウド IaC・リソース管理 コスト最適化 セキュリティチーム 脆弱性管理 コンプライアンス SLO設定 自動化・IaC 運用標準 SREの時間配分目標 自動化・改善・工学的作業: 50%以上 Toil（手作業の運用）: 50%以下

関連する規格・RFC

規格・RFC番号内容
Google SRE BookSREの実践を定義したバイブル。無料オンライン公開（sre.google）
OpenSLOSLO定義の標準化仕様（CNCF Sandbox）
DORA MetricsSREが参照するDevOps成熟度の4指標（デプロイ頻度・リードタイム・障害率・復旧時間）

関連用語