はじめに
本記事は、O'Reillyの『Site Reliability Engineering: How Google Runs Production Systems』（邦題：SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム）を読み通しての総まとめです。
SREとはGoogle発の概念で、「ソフトウェアエンジニアに運用チームの設計を依頼したらどうなるか」という問いから生まれた職種・文化・プラクティスの体系です。本書はその全貌を34章＋付録で解説しており、エンジニアリングと運用の両方に関心を持つ方にとって非常に示唆に富む一冊です。
本書は全5部構成になっています。
| 部 | テーマ |
|---|---|
| 第Ⅰ部 | イントロダクション |
| 第Ⅱ部 | 原則 |
| 第Ⅲ部 | プラクティス |
| 第Ⅳ部 | マネジメント |
| 第Ⅴ部 | まとめ |
第Ⅰ部：SREとは何か
従来のシスアド型運用との決別
従来のサービス管理では、「開発（dev）」と「運用（ops）」が別チームに分かれ、両者の目標が構造的に対立していました。開発チームは新機能を素早くリリースしたく、運用チームはサービスの安定を優先します。この分断が、リリース速度と信頼性のトレードオフを生み出していました。
Googleが選んだアプローチはシンプルです。ソフトウェアエンジニアを採用して、そのエンジニアに運用をさせる。繰り返しの手作業をソフトウェアで代替させることで、運用負荷がトラフィックに比例して増大する構造を断ち切ることができます。
SREの信条：「私たちが求めているシステムは、単に自動化されたものではなく、自動的に動作するものなのです」
SREの基本構造
GoogleのSREチームは大きく2種類のエンジニアで構成されます。
- 50〜60%：標準的なGoogleのソフトウェアエンジニア採用プロセスを通じた人材
- 40〜50%：ソフトウェアエンジニアの要件をほぼ満たし、加えてUNIXの内部やネットワーク（L1〜L3）に精通した人材
全SREに共通するのは「複雑な問題をソフトウェアで解決しようとする信念と適性」です。
SREの7つの信条
- エンジニアリングへの継続的な注力：運用作業の上限を50%とし、残りを開発に充てる
- SLOを下回らない範囲での変更速度の最大化：エラーバジェットの活用
- モニタリング：人間の解釈を挟まず、ソフトウェアが解釈し必要なときだけ通知する
- 緊急対応：手順書の整備によりMTTRを約3倍改善
- 変更管理：約70%の障害は変更によって発生。漸進的ロールアウトと自動ロールバックで対処
- 需要予測とキャパシティプランニング：自然成長と突発成長の両方を見越した計画
- プロビジョニングと効率：キャパシティとパフォーマンスの最適化
第Ⅱ部：原則
SLI / SLO / SLA の三層構造
本書でもっとも基礎的かつ重要な概念が、このサービスレベルに関する用語の定義です。
SLI（Service Level Indicator）
→ サービスの挙動を計測する指標（レイテンシ、エラー率、可用性など）
SLO（Service Level Objective）
→ SLIのターゲット値（例：99パーセンタイルのレイテンシ ≦ 100ms）
SLA（Service Level Agreement）
→ SLOを含む契約。違反時にペナルティが発生する
注意：業界では「SLA違反」という言葉が「SLO未達成」の意味で使われることが多いですが、本書は両者を明確に区別しています。
よくあるSLIの種類
| サービス種別 | 主要なSLI |
|---|---|
| ユーザー向けサーバー | 可用性・レイテンシ・スループット |
| ストレージシステム | レイテンシ・可用性・耐久性 |
| ビッグデータパイプライン | スループット・エンドツーエンドレイテンシ |
| すべてのシステム | 正確性 |
SLOのターゲット設計における注意点
- 現在のパフォーマンスをそのままターゲットにしない
- 「常に」「絶対に」といった絶対値を避ける
- 必要最低限のSLOのみを定義する
- 最初から完璧でなくてよい（緩めに始めて引き締める）
エラーバジェットの思想
100%の可用性を目標とすることは、ほぼ常に誤りです。ユーザーとサービスの間には複数のシステムが介在しており、エンドユーザーが体感できる可用性は99.999%をはるかに下回るためです。
そこで「1 - SLO」をエラーバジェットとして設定し、そのバジェットの範囲内でリスクを取って機能をリリースするというモデルが成立します。
エラーバジェットモデルによって、SREと開発チームの目標対立が解消されます。両者の共通目標は「機能リリースの速度を最大化しながらバジェットを使い切らないこと」になります。
トイルの排除
**トイル（Toil）**とは、手作業で繰り返し、自動化できるにもかかわらずしていない作業のことです。トイルはサービスの成長に比例して増加し、エンジニアの50%以上の時間を占めてしまう危険があります。
GoogleはSREの運用作業を50%以下に制限する方針を明文化しており、超過した場合は作業を開発チームに差し戻します。これは「開発チームへの懲罰」ではなく、「手作業を必要としないシステムを作るインセンティブ設計」です。
第Ⅲ部：プラクティス
モニタリングの設計
モニタリングの出力は3種類に分類されます。
| 種類 | 内容 |
|---|---|
| アラート | 即座に人間のアクションが必要な通知 |
| チケット | 数日以内に対処すれば良い通知 |
| ロギング | 人間が読む必要はないが診断・フォレンジック用に記録 |
重要なのは、人間の解釈を必要とするアラートは設計の欠陥という原則です。ソフトウェアが状況を解釈し、アクションが必要なときのみ人間に通知する設計を目指します。
また、メトリクスは平均よりも**パーセンタイル（分布）**で考えるのが基本です。50ms で処理されているリクエストの中に、5%は1000ms超というロングテイルが潜んでいることがあります。99パーセンタイルのレイテンシを改善することで、通常体験の品質が担保できます。
オンコール対応
SREのオンコールは、1シフト（8〜12時間）あたりのイベント数が平均2件以内になるよう設計されます。これを超えると、エンジニアがイベントの調査と学習に十分な時間を取れず、疲弊して対処品質が下がるためです。
オンコールシフトでは必ず**手順書（runbook）**を用意します。手順書があるエンジニアは、即興で対応するエンジニアに比べて、MTTRが約3倍改善されるというデータがあります。手順書はすべての状況をカバーはできませんが、リスクが高く時間のプレッシャーがある場面での「判断の足がかり」として機能します。
効果的なトラブルシューティング
1. 問題の把握（何が起きているか）
2. 仮説の形成（原因の候補）
3. 診断（仮説の検証）
4. 修正
5. ポストモーテム（再発防止）
トラブルシューティングはスキルとして学習・訓練できます。初心者が陥りやすい罠は「最初に思いついた仮説にとらわれる」ことであり、仮説を体系的に検証するアプローチが重要です。
インシデント管理
大規模なインシデントは明確な役割分担で対応します。
| 役割 | 責務 |
|---|---|
| インシデント指揮者 | 全体統括・意思決定 |
| オペレーション担当 | 実際の修正作業 |
| コミュニケーション担当 | ステークホルダーへの報告 |
| 計画担当 | チケット管理・ドキュメント記録 |
重要な原則は「実際に行動しているエンジニアを指揮から解放する」ことです。指揮者が作業者を兼任すると、状況の俯瞰ができなくなります。
ポストモーテム文化
本書でとくに印象的なのが、**非難のないポストモーテム（Blameless Postmortem）**の文化です。
ポストモーテムの目的は責任追及ではなく、以下を達成することです。
- インシデントの詳細をドキュメント化する
- すべての根本原因を十分に理解する
- 再発を防止する予防策を導入する
「インシデントに関わった全員が善意の下で、知り得た情報をもって正しい行動をとったものとして考える」という前提に立つことが、非難のないポストモーテムの基盤です。
非難文化が広まると、人々は処罰を恐れて問題を隠すようになります。その結果、問題は悪化してから発覚し、組織全体のリスクが高まります。一方、非難のない文化では問題が早期に共有され、システムとプロセスを継続的に改善できます。
ポストモーテムの作成条件（例）
- ユーザーへの影響が一定の閾値を超えたダウンタイム・デグレデーション
- データ損失が発生した場合
- オンコールエンジニアによる手動介入（ロールバック等）が必要だった場合
- モニタリングの障害（手動でインシデントを発見した場合）
信頼性のためのテスト
本番環境の信頼性を高めるテスト戦略として、以下が紹介されています。
- ユニット・インテグレーションテスト：基本的な品質担保
- システムテスト：エンドツーエンドの動作確認
- 障害インジェクション（カオスエンジニアリング）：意図的に障害を注入し、システムの耐性を検証
- ストレステスト：キャパシティの限界を把握
- ディザスタロールプレイング（不運の輪）：過去のポストモーテムを再現し、対応能力を訓練
第Ⅳ部：マネジメント
SREの採用と育成
新人SREの育成において重要なのは、早い段階でオンコールのシャドウイングを行うことです。システムの動作を実際の障害対応を通じて学ぶことが、効果的なリバースエンジニアリング思考を育みます。
また、SREが運用過負荷に陥った場合の対処法として「一時的なSRE移籍」というアプローチが紹介されています。これはチームに外部SREを加え、チケット処理ではなくプラクティスの改善そのものに集中させる手法です。
SREのエンゲージメントモデル
新サービスのSREサポート開始にあたっては、以下のステップを踏みます。
- サービスを評価してSREのサポートに値するかを確認
- SREのサポートの妨げとなる問題を交渉・改善
- 実際のSRE移管
サービスがSLOを継続的に達成できない場合、SREはオンコールローテーションから離脱し、開発チームが運用を引き取ります。これはペナルティではなく、「開発チームが運用の複雑さを自ら体験し、改善に動くインセンティブ」として機能します。
リリースエンジニアリング
SREが担うもう一つの重要な責務がリリースエンジニアリングです。信頼性の高いリリースプロセスは、以下の特性を持つ必要があります。
- 再現性：同じソースから同じバイナリが生成されること
- 自動化：人手によるステップを排除し、ミスを構造的に防ぐ
- 段階的ロールアウト：全トラフィックに一度に適用せず、カナリアリリースで問題を早期検出する
- 高速なロールバック：問題検出時に即座に前のバージョンへ戻せること
「70%の障害は変更によって起きる」という観察に基づき、変更をどう安全に扱うかがSREの中核的な仕事の一つになっています。
SRE内外の定期的なプロダクションミーティングが重要な役割を果たします。このミーティングでは直近のインシデント、オンコールの負荷、SLO達成状況、運用作業の傾向などをレビューし、改善の方向性を議論します。
インフラアーキテクチャの章から得られる知見
ロードバランシング
本書では、フロントエンドとデータセンター内の2層のロードバランシングが詳しく解説されています。
- フロントエンドのロードバランシング：DNS・エニーキャストベースでユーザーを最適なデータセンターへ誘導する
- データセンター内のロードバランシング：RPC呼び出しを最適なバックエンドサーバーへ分散する。過負荷サーバーへのリクエスト送信を避けるため、「最小コネクション数」や「リソース使用率ベース」の重み付けが使われる
カスケード障害への対応
分散システムで特に危険なのがカスケード障害です。あるサーバーへの負荷集中が連鎖的に全体を巻き込む現象で、以下のような対策が有効です。
- リクエストのデグレード：負荷が高いときは品質を落とした応答を返す
- サーキットブレーカー：障害のある依存先へのリクエストを遮断する
- 指数バックオフ付きリトライ：リトライがさらなる負荷を生まないようにする
データ処理パイプラインの信頼性
バッチパイプラインはリアルタイムサービスと異なる信頼性の問題を持ちます。重要なのはパイプラインの「正確性」と「進行状況の可視性」です。チェックポイントの設計や冪等性の担保が、長時間動作するジョブの信頼性を高めます。
第Ⅴ部：他業界との比較
最終章では、SREのプラクティスを航空・医療など「信頼性が命取りになる業界」と比較しています。ポストモーテムの文化、手順書の整備、障害インジェクションといったプラクティスは、これらの業界が長年かけて確立してきたものと多くの共通点を持っています。
本書を読んで感じたこと
「自動的に動作するシステム」という目標の明快さ
本書を貫く哲学は、「同じことを繰り返させるな、自動化せよ」という一点に集約されます。これはエンジニアの怠惰ではなく、スケールするシステムを持続可能にするための設計思想です。
SLO設計は「ビジネス判断」である
SLOは技術的な指標のように見えますが、本書が繰り返し強調するのは「SLOはプロダクトチーム・ビジネスチームが決める判断」だということです。エンジニアは可能性とリスクをアドバイスする立場にあり、最終的な目標値の決定はビジネスの優先順位に依存します。
非難のない文化はシステム設計の問題でもある
ポストモーテムの非難文化を排除するだけでは不十分で、「問題を報告すれば評価される」という報酬設計まで含めて文化が成立します。GoogleがLarry Pageを含む全社的な場でSREのインシデント対応を称えるのは、その仕組みの一例です。
まとめ
本書は34章という大ボリュームですが、「SREとは何か」「なぜその哲学が必要か」「どのプラクティスが現場を支えるか」を体系的に学べる稀有な一冊です。
- SREを導入・検討しているチームにとっては実践のガイドブック
- 開発者にとっては「運用とは何か」を理解するための視点
- 設計者にとっては「信頼性を設計に組み込む」とはどういうことかの教科書
SLO・エラーバジェット・ポストモーテムといったキーワードを知識として知っている方も、本書を通じてその背後にある哲学と実践の文脈を掴んでもらえれば、日々の設計判断の質が変わると思います。
参考文献：Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Murphy 著 / 澤田 武男, 関根 達夫, 細川 一茂, 矢吹 大輔 監訳「SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム」オライリー・ジャパン