はじめに
本記事は、O'Reilly の 『The Site Reliability Workbook: Practical Ways to Implement SRE』（邦題『サイトリライアビリティワークブック ―SREの実践方法』）を通読した際の書評・総まとめです。
前作にあたる『SRE サイトリライアビリティエンジニアリング』（通称「SRE 本」）が 「Google はなぜそう考えるのか」 を語った本だとすれば、本書は 「では自分の組織で明日から何をするのか」 に答える本です。
設計・アーキテクチャに関心のあるエンジニアにとって、本書は単なる運用手法のカタログではありません。信頼性を非機能要件ではなく、システムの第一級の「機能」として設計に組み込むための考え方が、全編を通して一貫して語られています。
以下、全 21 章 + 付録を 3 部構成に沿って整理し、最後に設計者視点での学びをまとめます。
本書の位置づけ
| 観点 | 『SRE サイトリライアビリティエンジニアリング』 | 『サイトリライアビリティワークブック』（本書） |
|---|---|---|
| 主題 | 原理・哲学 | 実装・手順・意思決定 |
| 読後感 | 「なるほど、そういう考え方か」 | 「これは自分のチームでも試せる」 |
| 事例 | ほぼ Google 社内 | Evernote / The Home Depot / Spotify / Niantic / New York Times / PagerDuty など社外事例が多数 |
| 規模の前提 | Google スケール | 小規模チーム・SRE 不在の組織も明示的に対象 |
本書の「はじめに」では、SRE が「Google の規模」や「Google の文化」でしか実践できないという誤解を解くことが目標として掲げられています。実際、各章には「うちは Google ではないのですが」という問いに対する回答が繰り返し登場します。この姿勢が、本書を極めて実務的なものにしています。
前作を読んでいなくても本書単体で読み進められますが、各章の冒頭で「詳細は前作の N 章を参照」という参照が頻出します。前作を横に置きながら読むと理解が深まります。
全体構成
本書は大きく 3 部に分かれています。
- 第Ⅰ部 基礎（1〜7 章）: SLO、モニタリング、アラート、トイル、単純さ
- 第Ⅱ部 実践（8〜16 章）: オンコール、インシデント対応、ポストモーテム、負荷管理、システム設計、パイプライン、設定、カナリア
- 第Ⅲ部 プロセス（17〜21 章）: 過負荷、エンゲージメントモデル、組織外への展開、チームのライフサイクル、変更管理
「技術 → 運用実践 → 組織」という順に、扱う対象のスコープが段階的に広がっていく構成になっています。
第Ⅰ部 基礎 — SLO がすべての起点
1 章 SREとDevOpsとの関係
章の冒頭に置かれた class SRE implements interface DevOps という一文が、本書全体の姿勢を象徴しています。
DevOps を、サイロの解体・自動化・リーン・計測・共有（CALMS）からなる緩やかな哲学のインターフェースとして捉え、SRE をその具体的な実装クラスの 1 つとして位置づける整理です。両者を対立軸で語る議論に対する、明快な回答になっています。
特に印象的だったのは「アクシデントは普通のこと」という原則です。障害を個人の失敗ではなく、防護策の欠如というシステム設計上の問題として扱う。この視点は、後半のポストモーテム文化の章に直結していきます。
2 章 SLOの実装
著者自身が「本書の中で最も重要な章」と述べている章です。
要点は明快です。エンジニアは有限のリソースであり、どこに信頼性の投資を行うかをデータで決める必要がある、というものです。そしてその判断基準が SLO とエラーバジェットです。
本書は、エラーバジェットベースのアプローチを導入するための前提条件を明示しています。
- プロダクトに適した SLO があり、全ステークホルダーが承認していること
- SLO を満たす責任を負う人々が、通常時にはそれを満たせると同意していること
- 意思決定と優先順位付けにエラーバジェットを使うことに組織がコミットしていること
- そのコミットメントがエラーバジェットポリシーとして公式化されていること
- SLO を改訂するプロセスが存在すること
これらが満たされない場合、SLO は単なる KPI が 1 つ増えただけの状態に堕してしまう、と釘を刺しています。ここは非常に耳が痛い指摘でした。
また「SLO がなければ、SRE の必要性もない」という趣旨の記述もあり、SRE の存在意義を SLO に紐付けて定義している点が徹底しています。
3 章 SLOエンジニアリングのケーススタディ
Evernote と The Home Depot の 2 社が、SLO とエラーバジェットをどう導入したかを一人称で語る章です。
Evernote の事例は、旧来の ops / dev 分離からの脱却というよくある課題から始まります。「開発が書いて開発が動かす」モデルと「開発が書いて運用が動かす」モデルの双方を試した末に、SLO 中心の SRE アプローチへ移行した、という試行錯誤の記述がリアルでした。
技術書のケーススタディは総花的になりがちですが、本章は失敗した過程まで含めて書かれているため、実際に導入を検討する立場だと参考になる密度があります。
4 章 モニタリング
モニタリングシステムを選定・評価するための観点が整理されています。
- 速度: データの鮮度と取得速度。4〜5 分以上古いデータはインシデント対応速度に大きく影響する
- 計算: 長期保持、集計、ウィンドウ関数のサポート
- インターフェース: グラフとダッシュボードの表現力
- アラート: 分類・抑制・通知の柔軟性
- ソース: メトリクスと構造化ログの使い分け
特に、保持するメトリクスは単調増加するカウンターであるべき、という指摘は実装レベルで効いてきます。カウンターであればモニタリングシステム側で任意のウィンドウのレートを計算でき、それがそのまま次章のバーンレートアラートの構成要素になります。
5 章 SLOに基づくアラート
個人的に、本書で最も実装に直結すると感じた章です。
アラート戦略の評価軸として、以下の 4 つが提示されます。
| 指標 | 意味 |
|---|---|
| 適合率（Precision） | 検出されたイベントのうち、重大だったものの割合 |
| 再現率（Recall） | 重大なイベントのうち、検出できたものの割合 |
| 検出時間 | 通知までにかかった時間 |
| リセット時間 | 問題解決後もアラートが鳴り続けた時間 |
そして、この 4 つを同時に良好に保つアラートルールを、素朴な方法から段階的に改良していく形式で 6 つ提示します。
最初のアプローチは「短いウィンドウのエラーレートが SLO の閾値を超えたらアラート」という単純なものです。
# アプローチ1: 直近10分のエラーレートが SLO 閾値を超えたら通知
- alert: HighErrorRate
expr: job:slo_errors_per_request:ratio_rate10m{job="myjob"} >= 0.001
これは実装は簡単ですが、適合率が低く（一瞬のスパイクで鳴る）、リセット時間も長くなります。本書はこの弱点を明示した上で、
- ウィンドウを長くする
- 複数ウィンドウを組み合わせる
- バーンレート（エラーバジェットの消費速度）でアラートする
- 短期ウィンドウと長期ウィンドウを組み合わせた多段バーンレートにする
と順に改良し、最終的な推奨形（アプローチ 6）へ到達します。
「なぜその形に落ち着くのか」を、失敗する設計から順に辿らせる構成になっているため、単にルールをコピーするのではなく、自分のサービスに合わせて調整できる理解が得られます。この章だけでも本書を読む価値があると感じました。
低トラフィックなサービスでは、この手法はそのままでは機能しません。本書ではリクエストの人工的な生成、サービスの結合、クライアント側での再試行など、低トラフィック環境向けの対処も別途扱われています。
6 章 トイルの撲滅
トイルを「サービスのメンテナンスに関係し、繰り返され、予想可能で、定常的なタスクの流れ」と定義し、その特徴をスペクトラムとして整理します。
- 手作業である
- 繰り返される
- 自動化可能である
- 非戦略的 / リアクティブである
- 持続的な価値がない
- サービスの成長と同じ速度で増える
最後の項目が設計者にとって最も重要だと感じました。トイルが線形に増えるということは、それはアーキテクチャ上のスケーラビリティ欠陥であるということです。運用工数の増加曲線を、システム設計の評価指標として扱う視点は新鮮でした。
また本書は、トイルがチームの士気を静かに削る点にも紙幅を割いています。作業手順書が「ログインして、コマンドを実行して、出力を確認して……」という形になっているなら、それは実質的に擬似コードであり、自動化の候補である、という指摘は分かりやすい判断基準です。
7 章 単純さ
うまく動作する複雑なシステムはいずれも、うまく動作するシンプルなシステムから進化したものである（Gall の法則）
複雑さの計測が難しいことを認めた上で、システムレベルの複雑さの実用的な代用指標を提示しているのが本章の価値です。
- トレーニング時間: 新メンバーがオンコールに入るまでの期間
- 説明の時間: アーキテクチャ全体をホワイトボードで説明するのにかかる時間
- 管理の多様性: 同じ設定を行う方法がいくつあるか
- デプロイされている構成の多様性: 本番に存在するユニークな構成の数
- 年代: システムの経過年数（Hyrum の法則）
そして、複雑さは外部性であるという指摘が刺さりました。複雑さを持ち込んだ本人がコストを払うとは限らず、その周辺で作業し続ける人々が払うことになる。だからこそ、あらゆる場面で単純さを擁護する役割が必要になる、という論理展開です。
第Ⅱ部 実践 — 現場のプロセスを設計する
8 章 オンコール
前作の該当章に寄せられたフィードバックへの回答という形を取った、実務的な章です。
- ローテーションに人数が足りない小規模チームはどうするか
- 開発者と DevOps が混在するローテーションをどう編成するか
- 1 シフトで 100 回ページが飛ぶ状態をどこから改善するか
- 交代率が高い場合の知識ギャップにどう対応するか
こうした具体的な問いに、Google 内外の複数の構成パターンを示しながら答えていきます。オンコールを「気合い」ではなく設計対象のシステムとして扱う姿勢が徹底しています。
9 章 インシデント対応
Google と PagerDuty 双方のインシデント管理体制を紹介する章です。
基盤となっているのは、1968 年に消防が山火事対応のために確立した ICS（Incident Command System） です。ソフトウェア障害対応がこの枠組みを借りているという事実そのものが興味深い点でした。
基本原則は以下の 4 点に集約されています。
- 明確な指揮系統の管理
- 明確に規定された役割の割り当て
- 対応と並行してデバッグ・緩和の作業記録をつける
- インシデントの宣言を早期に、頻繁に行う
最後の項目は特に実践的です。「大げさかもしれない」と躊躇して宣言が遅れることのコストのほうが、はるかに大きいという判断です。
10 章 ポストモーテムの文化：失敗からの学び
ラック撤収の自動化バグと不十分なレート制限が組み合わさり、数千台のサーバーが同時にオフラインになった Google の実障害をケーススタディとして扱います。
秀逸なのは、同じインシデントについて「良くないポストモーテム」と「良いポストモーテム」を並べて提示する構成です。抽象的に「非難のない文化が大事です」と説くのではなく、文書の書き方の差として何が起きるかを見せてくれます。
また、ポストモーテム文化が壊れ始めた初期症状（形式だけの文書、責任追及への回帰、アクションアイテムの放置など）と、その改善方法にも言及があります。導入だけでなく維持を扱っている点が実践的です。
11 章 負荷の管理
Google Cloud Load Balancer（GCLB）を題材に、トラフィック管理の全体像を扱う章です。
- DNS ベースのロードバランシングの限界
- Maglev / GFE / GSLB といった多層構成
- オートスケーリングとロードバランシングの相互作用
- Niantic の Pokémon GO のケーススタディ
Pokémon GO の事例は、想定の数十倍のトラフィックが到来した際に何が起きたかが具体的に書かれており、キャパシティプランニングの前提が崩れたときの挙動を知る教材として読み応えがありました。
12 章 非抽象的な大規模システム設計の紹介
設計・アーキテクチャに関心があるなら、本書で最も面白い章の 1 つです。
NALSD（Non-Abstract Large System Design） は、ホワイトボード上の設計を具体的なリソース量へ変換することを繰り返し訓練する設計手法です。
「非抽象的」を掲げる理由は明確です。すべてのシステムは最終的に、実在のデータセンターの実在のマシン上で動作します。この変換を精密に行わないと、現実世界に対応できないシステムを容易に作り出してしまうからです。
そして本書は、重要なのは最終的な数値そのものではなく、その数値に至る理由付けと仮定の置き方であると繰り返し強調します。初期の仮定が計算結果を大きく左右するため、仮定を明示し、それを検証可能にしておくことに価値がある、という主張です。
「信頼性はあらゆるプロダクションシステムにおいて最も重要な機能である」という本書全体を貫く主張が、設計手法として具体化されているのが本章です。
13 章 データ処理パイプライン
バッチ、ストリーミング、Lambda / Kappa アーキテクチャといったパイプラインのパターンを整理した上で、パイプライン固有の信頼性課題を扱います。
- データの鮮度（freshness）と正確性をどう SLI に落とすか
- パイプラインの「健全性シグナル」をどう計測するか
- 開発サイクル全体を通じたベストプラクティス
Spotify のイベント配信パイプラインのケーススタディが収録されており、自社開発・Google Cloud・サードパーティを組み合わせた実構成が語られます。
パイプラインの遅延や誤りは、最終的にユーザーに見える問題として顕在化する。この因果を SLO に接続する発想は、データ基盤の設計をしている方には直接役立つはずです。
14 章 設定の設計とベストプラクティス
設定を、人間とコンピュータの間のインターフェースとして捉え直す章です。
システムを「ソフトウェア」「データセット」「設定」の 3 コンポーネントに分けた上で、設定インターフェースの品質が、コード品質と同じように長期的な保守性へ効いてくると論じます。
設定変更が行われる状況を、
- 時間的余裕のある初期セットアップ時
- インシデント対応中の緊急の再設定時
の 2 つに分けている点が実務的です。後者で事故が起きない設計になっているか、という問いは重い。
15 章 設定の詳細
14 章の理論を受けて、より具体的な設定システムの話に踏み込みます。
本章の白眉は、トイルの二段階という整理です。
- レプリケーショントイル: 同じ設定がシステム中に複製され、変更のたびに複数箇所を更新する必要がある
- 複雑さのトイル: レプリケーショントイルを解消するために設定言語や自動化を導入した結果、その自動化が生む予期しない挙動に対処する羽目になる
つまり、トイルを解消する手段が次のトイルを生むという構造です。マイクロサービスアーキテクチャでは特にレプリケーショントイルが起きやすく、そこに設定言語を導入すると複雑さのトイルへ移行しやすい。この力学を知っているかどうかで、設定基盤の設計判断は変わってきます。
16 章 カナリアリリース
リリースエンジニアリングの原則を整理した上で、カナリアリリースを評価の設計問題として扱います。
前提となる原則は以下の通りです。
- 再現可能なビルド
- 自動化されたビルド
- 自動化されたテスト
- 自動化されたデプロイメント
- 小規模なデプロイメント
その上で、カナリアの本質は「一部にデプロイすること」ではなく「カナリア群とコントロール群を比較して、ロールアウト継続の可否を判断すること」だと定義されます。実質的に A/B テストのプロセスである、という捉え方です。
カナリア母集団のサイズ、評価に必要な観測時間、メトリクスの選択といったトレードオフが体系的に整理されており、CI/CD パイプラインを設計する際のチェックリストとして使えます。
第Ⅲ部 プロセス — 組織としての持続可能性
17 章 過負荷の特定と回復
チーム自体が過負荷に陥ったときの回復方法を扱う、やや異色の章です。
運用負荷は「ページ」「チケット」「継続的な運用責任」の 3 種類に分類され、そのうちページと緊急チケットはエンジニアリング作業への割り込みとして扱われます。
Google SRE では運用作業を時間の 50% に制限していますが、重要なのは数字そのものではなく、上限を設けること自体が最適化の第一歩になるという考え方です。
過負荷は単に進捗を止めるだけでなく、ミスの確率を上げて信頼性を損ない、最終的にユーザーに影響するという因果が明示されており、チームの健全性を信頼性の一部として扱う姿勢が一貫しています。
18 章 SREのエンゲージメントモデル
「SRE チームは、どのサービスをどこまで見るのか」を決める章です。
マイクロサービス化により、小規模な企業でも単一の SRE チームが扱える以上のサービス数を容易に持ちうるという現実を出発点にしています。すべてをカバーできない前提で、どこに注力するかを開発チームと協働して決める、という現実的なアプローチです。
PRR（プロダクションレディネスレビュー）などの手法に加え、サービスのライフサイクル全体を通じた関与レベルの推移が図示されており、「ページャーを受け取る前」に SRE が貢献できる領域が広いことが強調されています。
19 章 SRE：壁の向こうへの到達
短いながら、本書の思想が最も凝縮されている章です。提示される原則を抜き出すと以下のようになります。
- 信頼性は最も重要な機能である
- モニタリングではなく、ユーザーが信頼性を決める
- プラットフォームを運用するなら、信頼性はパートナーシップである
- すべてが重要なら、何も重要ではない
2 番目が特に本質的だと感じました。「モニタリング上は問題ありません」という説明は、実際に不安定さを体験しているユーザーには何の意味も持ちません。ピークエンドの法則が引かれ、ユーザーは体験を記憶し、次の選択時にそれを思い出すと述べられます。
モニタリングやログの価値は、あくまで「顧客より先に気づけること」にある。この主従関係の整理は明快でした。
20 章 SREチームのライフサイクル
SRE が 1 人もいない組織から始めて、成熟したチームへ至るまでのロードマップを、原理番号付きで提示する章です。
出発点となるのは以下です。
原理 #1: SRE は重大な結果を伴う SLO を必要とする
つまり、SRE という職種を採用する前に SRE のプラクティスは始められるという主張です。具体的には、
- 100% の信頼性を求めていないことを認める
- ユーザーにとって最も重要な信頼性を計測する SLO を設定する
- エラーバジェットポリシーに合意する
- 計測とポリシー順守にコミットする（経営層の同意が必要）
この 4 点は、SRE の採用計画がない組織でも今日から着手できます。「暗黙の 100% SLO はチームを受け身にする」という指摘は、多くの現場に当てはまるのではないでしょうか。
その後、最初の SRE の採用（運用・ソフトウェアエンジニアリング・モニタリングの 3 領域を面接で見る）、チームの分割、地理的分散へと段階が進んでいきます。
21 章 SREにおけるIT変更管理
Lewin の「解凍－変化－再凍結」モデルなど、組織変更管理の古典的理論を SRE の文脈に当てはめる章です。
技術書としてはやや異質ですが、SRE の導入自体が組織変更のプロジェクトであるという認識に立てば、必要な章だと納得できます。理論の形式的なプロセスをそのまま適用するのではなく、フレームワークとして思考の補助に使う、という距離の取り方も現実的でした。
付録 — 実務でそのまま使えるテンプレート群
- 付録 A: SLO ドキュメントの例
- 付録 B: エラーバジェットポリシーの例
- 付録 C: ポストモーテム分析の結果
本書の価値を大きく押し上げているのが、この付録です。特に付録 A と B は、SLI の定義、計測方法、境界条件、ポリシー発動時のアクションまで含む実文書の形になっており、自組織のドキュメントの雛形としてそのまま流用できる水準です。
理論を読んで納得しても、最初の一文が書けずに止まることは多いものです。その障壁を下げてくれます。
設計・アーキテクチャの観点で得られた学び
読み終えて、設計者として持ち帰れると感じた点を整理します。
1. 信頼性は非機能要件ではなく「機能」である
本書は一貫して、信頼性を最優先の機能として扱います。設計時に信頼性を先送りすることは、より高いコストでより少ない機能しか実現できなくすることと同義である、という主張です。この立場を取ると、アーキテクチャレビューの論点が変わります。
2. 運用コストの増加曲線は、設計品質の指標である
トイルがサービスの成長と同じ速度で増えるなら、それはアーキテクチャの欠陥です。「このコンポーネントを 10 倍にスケールさせたとき、運用工数は何倍になるか」という問いは、設計段階で答えられるべきものです。
3. 設定は人間とのインターフェースであり、API と同格に設計すべき
設定インターフェースの品質は、コード品質と同じ時間軸で保守性に効いてきます。しかも、最も品質が問われるのはインシデント対応中の緊急変更時です。
4. 抽象的な設計は、具体的なリソース量に変換して初めて検証できる
NALSD の考え方です。QPS、レイテンシ、ディスク容量、マシン台数まで落とし込む。そして数値そのものより、そこに至る仮定を明示することが重要です。
5. 「単純さ」を擁護する役割を、組織として持つ
複雑さは外部性であり、持ち込んだ人がコストを払うとは限りません。だからこそ、単純さを擁護する役割を明示的に置く必要があります。
こんな方におすすめです
- 前作を読んで「考え方は分かったが、明日何をすればいいのか」で止まっている方
- SLO を導入したいが、最初の 1 本をどう定義すればよいか分からない方
- アラートが鳴りすぎている／鳴らなすぎている現場を抱えている方
- マイクロサービス構成で設定管理が破綻しかけている方
- SRE という職種がいない組織で、信頼性の改善を進めたい方
- システム設計を、具体的なリソース量まで落として検証する訓練をしたい方
逆に、SRE の概念を初めて知る方は、前作の 1〜3 章あたりを先に読んでから本書に入ると、参照の多さに戸惑わずに済むと思います。
まとめ
本書を一言でまとめるなら、**「信頼性に関する意思決定を、勘や気合いからデータへ移すための実装ガイド」**です。
- SLO とエラーバジェットが、すべての優先順位付けの起点になる
- アラートは「鳴らす条件」ではなく「適合率・再現率・検出時間・リセット時間」の設計問題である
- トイルの増加曲線は、アーキテクチャの評価指標である
- 設計は具体的なリソース量に変換して初めて検証できる
- そして、これらは Google の規模でなくても始められる
前作が「SRE とは何か」を語る本だとすれば、本書は「SRE をどう始めるか」を語る本です。すでに前作を読んでいる方にも、これから読む方にも、手を動かす段階で必ず戻ってくることになる 1 冊だと感じました。
読了後、まず付録 A と B を写経しながら自分の担当サービスの SLO ドキュメントを書き起こしてみることをおすすめします。理論として理解していたつもりの箇所が、書けないことで初めて分かります。
書誌情報
- 原題: The Site Reliability Workbook: Practical Ways to Implement SRE
- 邦題: 『サイトリライアビリティワークブック ―SREの実践方法』
- 編者: Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, Stephen Thorne
- 出版: O'Reilly Media