はじめに
本記事は、O'Reilly『Site Reliability Engineering: How Google Runs Production Systems』（邦題『SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム』）を通読したうえで、設計・アーキテクチャに関心のあるエンジニア向けに1本にまとめた書評です。
この本は「Googleの自慢話」ではありません。読み終えて残るのは、もっと乾いた主張です。
信頼性は、運用でなんとかするものではなく、設計と意思決定の対象である。
600ページ超という分量に怯む方も多いと思いますが、骨格自体は驚くほどシンプルです。本記事では、その骨格を先に示し、そのうえで各部の要点と、実務にどう持ち帰るかを整理していきます。
本書は2016年（邦訳2017年）の書籍です。ツールやミドルウェアの具体名は当然古くなっていますが、原則の部分はほとんど古びていません。むしろ現在のPlatform Engineering、SLOベースの運用、オブザーバビリティの議論は、本書を前提知識として進んでいる印象があります。
書誌情報
| 項目 | 内容 |
|---|---|
| 原題 | Site Reliability Engineering: How Google Runs Production Systems |
| 邦題 | SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム |
| 編者 | Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy |
| 監訳 | 澤田武男、関根達夫、細川一茂、矢吹大輔 |
| 訳 | Sky株式会社 玉川竜司 |
| 出版 | オライリー・ジャパン（原書 2016 / 邦訳 2017） |
| 構成 | 全34章 + 付録6本、5部構成 |
本書の構成
| 部 | テーマ | ざっくり言うと |
|---|---|---|
| 第Ⅰ部 | イントロダクション | なぜ「開発」と「運用」を分けると壊れるのか |
| 第Ⅱ部 | 原則 | SREが判断の拠り所にしている考え方 |
| 第Ⅲ部 | 実践 | 日々の運用と、分散システム固有の設計課題 |
| 第Ⅳ部 | 管理 | チームと人をどうスケールさせるか |
| 第Ⅴ部 | まとめ | 他業界との比較と総括 |
第Ⅱ部と第Ⅲ部が本体で、ページ数の大半を占めます。第Ⅳ部は組織論、第Ⅴ部はエッセイに近い読み味です。
第Ⅰ部：なぜSREという職種が生まれたのか
開発 / 運用分断のコスト
本書は、従来のシステム管理者（シスアド）モデルの構造的な問題から話を始めます。手作業での変更管理とイベント対応に依存すると、サービスの成長に比例してチームを大きくせざるをえません。これが直接的なコストです。
しかし本書がより重大だとするのは間接的なコストのほうです。開発チームと運用チームは、用語もリスクの見積もりも安定性の目標も異なります。本心では、開発チームは新機能を早くリリースしたい。運用チームはページャーを持っている間は何も起きてほしくない。そして障害の多くは変更によって引き起こされるため、両者の目標は構造的に対立します。
その結果として起きるのが、ローンチレビューという名の関門と、それを回避するための「ローンチではなくフラグ変更」という開発側の学習です。心当たりのある方は多いのではないでしょうか。
SREの定義
Ben Treynor Slossによる定義は明快です。
SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものである。
ポイントは「運用をソフトウェアエンジニアにやらせる」ではなく、**「運用チームそのものをソフトウェアエンジニアに設計させる」**という点です。人手で回していた作業を、システムに置き換えていく。この一文が本書全体の設計思想を規定しています。
そして具体的な担保として置かれているのが、有名な 50%ルール です。
- SREが運用作業（トイル）に費やす時間は、作業時間の50%以下に抑える
- 残り50%以上は、将来のトイルを減らすか、サービスに機能を追加するエンジニアリングに使う
この上限がないと、トイルは放っておけば時間の100%を埋め尽くします。組織としての明示的な予算配分になっているのが重要な点です。
第Ⅱ部：原則 ―― ここが本書の核心
3章：リスクの受容とエラーバジェット
本書でもっとも引用される考え方が、ここにあります。
100%を信頼性の目標にするのは、ほぼ常に誤りである。
理由は2つあります。ひとつは、信頼性を1桁上げるコストが指数的に増えること。もうひとつは、ユーザーがその差に気づかないことです。99%の信頼性のスマートフォンを使っているユーザーに、サービス側の99.99%と99.999%の差は見えません。ユーザー体験を決めているのは、より信頼性の低い経路のほうだからです。
ここから エラーバジェット が導かれます。
エラーバジェット = 1 - SLO
例）可用性SLOが99.99% の場合
→ 0.01% 分の「使えなくてよい時間」が予算として与えられる
運用ルールはシンプルです。
- バジェットに余裕があるうちは、開発チームは自由に新機能をローンチできる
- バジェットを使い切ったら、バジェットが回復するまで変更は凍結される（緊急のセキュリティ対応やバグ修正は除く）
これが効いてくるのは、SREと開発チームの対立を「感情」から「データ」に移すからです。「リスクが高いからリリースするな」ではなく、「今月の予算はもう残っていない」になる。同じ数字を見ながら、両チームが同じ目標（バジェットを吹き飛ばさずにローンチ回数を増やす）を追える設計です。
本書は可用性ターゲットを下限であると同時に上限でもあると捉えています。99.99%が目標なら、99.999%を目指すのは資源の誤配分です。過剰な信頼性は、機能追加・技術的負債の返済・運用コスト削減の機会を奪います。この「上げすぎも失敗」という感覚は、日本の現場ではかなり異質に映るところだと思います。
4章：SLI / SLO / SLA
用語が混同されやすい領域なので、本書は明確に分離しています。
| 用語 | 意味 | 例 |
|---|---|---|
| SLI（指標） | サービスレベルを表す、慎重に定義された計測量 | リクエストレイテンシ、エラー率、スループット、可用性 |
| SLO（目標） | SLIの目標値、または目標範囲 | 平均レイテンシ100ms以下 |
| SLA（合意） | SLOを満たさなかった場合の結果を含む、ユーザーとの契約 | 返金条項など |
実務上の勘所として本書が繰り返すのは以下の点です。
- SLIは選べるが、SLOは選べないものがある。 外部から来るQPSはユーザー行動で決まるため、SLOを置いても意味がありません
- SLIどうしは水面下でつながっている。 QPSが上がればレイテンシは悪化しがちで、ある閾値を越えると性能は劇的に落ちます
- 平均ではなくパーセンタイルで見る。 平均レイテンシは遅いリクエストの存在を隠します
- SLOの公表は期待値の設定でもある。 実力より高すぎるSLOは自分の首を絞めます
そして付録Bで念押しされているのが、計測点をユーザー側に寄せるという指針です。Gmailの事例では、エラー率とレイテンシをサーバーではなくクライアントで計測したところ可用性の評価値は大きく下がりましたが、それが正しい数字であり、結果として双方のコード改善が進み数年で99.0%から99.9%超へ改善したと述べられています。都合の悪い数字が出る計測こそ正しいという好例です。
5章：トイルの撲滅
トイルは「やりたくない仕事」ではありません。本書の定義は明確です。
- 手作業である
- 繰り返される
- 自動化できる
- 戦術的（割り込み駆動、事後対応的）である
- 長期的な価値を持たない
- サービスの成長に対してO(n)でスケールする
最後の項目が本質だと感じます。逆に言えば、チームミーティングや人事事務は「オーバーヘッド」であってトイルではないし、アラート設定の一括整理はつまらなくても永続的な改善を残すのでトイルではありません。
判定基準として、私は次の1行を使うようにしました。
それをやり終えた後、サービスは前と同じ状態のままか？
同じままなら、それはトイルです。
6章：分散システムのモニタリング
モニタリングの章で押さえるべきは、4大シグナルと、アラートの出力先の3分類です。
| 4大シグナル | 見るもの |
|---|---|
| レイテンシ | リクエスト処理にかかった時間（成功と失敗を分けて見る） |
| トラフィック | システムへの需要（QPS など） |
| エラー | 失敗したリクエストの率 |
| サチュレーション | リソースの逼迫度（もっとも制約となる資源） |
そして付録Bにある、モニタリング出力の3分類が強烈です。
| 出力 | 意味 |
|---|---|
| ページ | 人間が今すぐ何かをしなければならない |
| チケット | 人間が数日中に何かをしなければならない |
| ロギング | すぐに見る必要はないが、後の分析のために記録される |
つまり、「アラートメール」というカテゴリは存在しません。本書はこう書いています。
アラートをメールに含め、誰かがそれらをすべて読んで重要なものに気づいてくれることを祈るのは、職業倫理的にはアラートを/dev/nullへパイプすることと変わりない。
人間の無限の警戒心に依存した設計は、いつか必ず破綻する。ここは多くのチームに刺さる指摘だと思います。
また、ホワイトボックス（内部メトリクス）とブラックボックス（外部から見た振る舞い）の使い分けも重要です。ブラックボックスは「今まさに壊れている」を捉え、ホワイトボックスは「もうすぐ壊れる」と原因の特定を担います。
7〜9章：自動化・リリースエンジニアリング・単純さ
- 7章 自動化の進化：自動化の価値は「人間より速い」ことよりも、一貫性・プラットフォーム化・修復時間の短縮にあります。そして本書は「自動化されたプロセスの壊れ方は、手作業の壊れ方より派手になりうる」という副作用にも正直です
- 8章 リリースエンジニアリング：リリースを専門職能として位置づけ、密封ビルド（hermetic build）、設定のバージョン管理、段階的ロールアウトを原則とします
- 9章 単純さ：SREはソフトウェアの単純さを推進する立場だと明言されます。「意図的でない複雑さ」はバグの温床であり、削除されるコード行は書かれないコード行と同じくらい価値があります
第Ⅲ部：実践
サービス信頼性の階層
第Ⅲ部の導入で示される「サービスの信頼性の階層」は、本書でもっとも実用的な図のひとつです。マズローの欲求段階になぞらえて、下から順にこうなります。
上 ┌ プロダクト
│ 開発
│ キャパシティプランニング
│ テストとリリース手順
│ ポストモーテム / 根本原因分析
│ インシデント対応
下 └ モニタリング ← これがないと何も始まらない
下の段が成り立っていないのに上の段に取り組んでも無駄になる、というのがこの図のメッセージです。モニタリングがない状態でキャパシティプランニングを議論しても意味がありません。自チームの現在地を測る物差しとして、そのまま使えます。
11〜14章：オンコールとインシデント対応
- オンコールは目的ではなく、システムの実態を体で知り続けるための手段である
- 対応の第一目標は根本原因の解決ではなく出血の止血である。デグレードさせる、機能を一部止める、健全なインスタンスへトラフィックを流す、といった選択肢を先に取る
- インシデント管理では、指揮者・実行担当・情報連絡担当といった役割を明確に分離する。誰が意思決定者かが曖昧なまま、全員が手を動かす状態が最悪です
12章の「効果的なトラブルシューティング」は、仮説検証のプロセスを言語化した章として単体でも価値があります。「問題の切り分け」を属人的な勘ではなく手順にする、という発想です。
15章：ポストモーテムの文化
SREの文化面での中核がここです。
ポストモーテムを書くのは処罰ではなく、会社全体としての学びの機会である。
非難を伴わない（blameless）ことが信条とされ、焦点は人ではなくシステムとプロセスに置かれます。重要なのは、書くかどうかを個人の判断に委ねないことです。本書は事前に条件を定義しておくことを求めます。
- ユーザーに影響するダウンタイムやデグレードが閾値を超えた
- 種類を問わずデータ損失が発生した
- オンコールエンジニアの介入（ロールバック、トラフィック迂回など）が必要だった
- 解決までの時間が閾値を超えた
- モニタリングが機能せず、人手でインシデントが発見された
条件を事前に決めておくことで、「これは書くほどのことか」という不毛な議論と、書くこと自体が懲罰に見える構造を避けられます。
17〜18章：テストとソフトウェアエンジニアリング
信頼性のためのテストの章では、単体・結合・システムテストに加えて、プロダクション環境でのテスト（設定テスト、ストレステスト、カナリアテスト）が正面から扱われます。「本番でテストするな」ではなく「本番で安全にテストする方法を設計しろ」という立場です。
18章では、SREがプロダクトを作る側でもあることが示されます。運用の知見を、ドキュメントではなくコードとして体系化する。ここがSREを単なる運用チームと分ける決定的な差です。
19〜27章：分散システムの設計課題
ここからは、アーキテクチャ寄りの読者にとって一番おいしい領域です。
| 章 | テーマ | 持ち帰れる原則 |
|---|---|---|
| 19-20章 | ロードバランシング | 「最も負荷の低いサーバーへ送る」は素朴すぎる。実際にはサブセット化と加重ラウンドロビンが要る |
| 21章 | 過負荷への対応 | QPSではなく必要リソース量でキャパシティを測る。クライアント側スロットリング、重要度の階層化 |
| 22章 | カスケード障害 | 過負荷が正のフィードバックを生み、システム全体を倒す構造とその防ぎ方 |
| 23章 | 分散合意 | 「クリティカルな状態の管理」。Paxos系を自作するな、という現実的な教訓 |
| 24章 | 分散cron | 「定期実行」を分散環境で正しくやることの難しさ |
| 25章 | データ処理パイプライン | 周期的パイプラインの構造的な脆さと、その改善 |
| 26章 | データの完全性 | バックアップではなくリストアを目標にする |
22章のカスケード障害は特に価値が高い章です。あるレプリカが過負荷で落ちると、残りのレプリカの負荷が上がり、落ちる確率が上がる。ドミノ倒しでサービス全体が停止する。この構造に対する具体的な対策として、以下が挙げられます。
- 適切なタイムアウトと、期限（deadline）の伝播
- 指数バックオフ + ジッター
- キューの深さを制限し、待たせるくらいなら早く落とす（fail fast）
- グレースフルデグラデーション
- 過負荷時に自動再起動しても状況は改善しないという認識
冒頭の格言が本質を突いています。
最初に成功しなかったら、指数的にバックオフすることだ。
26章のデータ完全性も示唆に富みます。ユーザーから見れば、データが失われたことと、長時間アクセスできないことは区別できません。したがってデータ完全性は可用性の問題でもある。そして「バックアップを取っている」ことに意味はなく、期限内にリストアできることだけが価値を持つ、という主張は耳が痛いところです。
第Ⅳ部：管理 ―― 人とチームのスケール
技術書として読み始めると飛ばしがちですが、再現性の鍵は実はここにあります。
- 28章 SREの成長：新人をオンコールに送り出すまでの育成を体系的なプロセスとして設計する。「見て覚えろ」を捨てる
- 29章 割り込みへの対処：担当を決めて集中的に引き受けることで、他メンバーの集中時間を守る
- 30章 運用過負荷からのリカバリ：溺れているチームを立て直すケーススタディ
- 31章 コミュニケーションとコラボレーション：プロダクションミーティングの運営方法まで具体的です
- 32章 エンゲージメントモデル：設計段階からの関与（PRR: Production Readiness Review）が要
特に32章は重要で、SREは全サービスを見るわけではありません。関与するかを判断し、基準を満たさないサービスは開発チームに返すこともある。この「引き受けない自由」がないと、SREは何でも屋の運用チームに退化します。
第Ⅴ部：まとめ ―― 他業界との比較
33章では、航空、防衛、医療機器、通信、水難救助といった高信頼性が求められる業界の経験者へのインタビューから、共通するテーマを4つ抽出しています。
- 準備とディザスタテスト
- ポストモーテムの文化
- 自動化と運用オーバーヘッドの低減
- 構造化された合理的な判断
つまりSREの原理は、IT業界固有のものではなく、高信頼性を扱う分野に共通する普遍的な工学的態度だという結論です。
34章のまとめでは、印象的な比喩が置かれています。100年前の飛行機はパイロットが整備も荷役も兼ねていた。現代の747は数百人と数トンの貨物を運び、6,000マイル先の滑走路に予定時刻の数分の誤差で降りる。それなのにコックピットにいるパイロットは、100年前と同じ2人だけ。
規模が1,000倍になっても、運用する人数を1,000倍にしない。それを可能にしたのは、考え抜かれたインターフェース、冗長性、そして訓練でした。SREが目指すのも同じ方向だ、と本書は締めくくります。
実務にどう持ち帰るか
Googleの規模でなくても導入できるものを、コスト順に並べてみました。
すぐできること
- 主要機能についてユーザー視点のSLIを1〜2個だけ定義する（まずはレイテンシとエラー率）
- 既存アラートを「ページ / チケット / ログ」に分類し直し、ページに残すものを絞る
- 読まれていないアラートメールを疑う。読まれていないなら、それはアラートではありません
- ポストモーテムを書く条件を、インシデントが起きる前に文書化する
数ヶ月かけて取り組むこと
- SLOを設定し、エラーバジェットの消費状況をダッシュボードに載せる
- チームのトイル比率を計測する（まずは概算でよい）
- 段階的ロールアウトを標準化し、異常時はまずロールバック、診断は後を徹底する
- リストア訓練を実施する。存在確認ではなく、期限内に戻せるかの検証
組織としての合意が要ること
- エラーバジェット枯渇時の変更凍結を、開発チームと事前に合意する
- トイル比率の上限（50%でなくてもよい）をチーム目標として明文化する
エラーバジェットは、プロダクト側との合意なしに導入すると単なるお題目になります。逆に言えば、合意さえ取れれば技術的な難易度は高くありません。
読み方ガイド
全34章を頭から読み通す必要はないと思います。目的別に。
| 目的 | 読む順 |
|---|---|
| SREの考え方を掴みたい | 1章 → 3章 → 4章 → 5章 → 6章 → 付録B |
| 運用チームを立て直したい | 第Ⅳ部（特に29〜32章）→ 15章 |
| 分散システムの設計を学びたい | 21章 → 22章 → 23章 → 26章 |
| 時間がない | 付録B「プロダクションサービスのためのベストプラクティス」だけ読む |
付録Bは、Ben Treynor Sloss本人が本書のエッセンスを数ページに凝縮したものです。ここだけ読んで、気になった項目から本編に戻るのが、もっとも効率のよい読み方だと感じました。
誤読しやすいポイント
- 「SREを名乗れば運用が良くなる」ではありません。 本書の実体は、50%ルールという時間の予算配分と、エラーバジェットという意思決定の仕組みです。看板だけ変えたチームは、本書の言う「運用チームへの退化」そのものです
- 「Google規模でなければ意味がない」でもありません。 BorgやJupiterはそのまま真似できませんが、SLO、エラーバジェット、トイルの定義、ポストモーテムの条件設定は5人のチームでも今日から使えます
- 「100%を目指さない」は手抜きの言い訳ではありません。 目標を下げるのではなく、目標を明示的に決めて根拠をユーザー体験に置くという話です。なんとなく「落ちないように頑張る」よりずっと厳しい規律を要求します
まとめ
本書を読んで変わったのは、「障害を減らす」という漠然とした目標を、次のように分解できるようになったことです。
- どのSLIを見るのか
- SLOはいくつか、その根拠は何か
- エラーバジェットの残りはどれだけか
- トイルに何%使っているか
- ポストモーテムの条件は決まっているか
信頼性は、努力や根性ではなく、測れて、予算化できて、設計できる対象である。これが本書のもっとも重要なメッセージだと思います。
2016年の本ですが、SLOやオブザーバビリティを扱う現在の議論は、ほぼすべて本書を前提にしています。遠回りに見えて、いちばん早い一冊でした。
参考
- Site Reliability Engineering（原書はGoogleが無料公開しています）: https://sre.google/sre-book/table-of-contents/
- 続編『The Site Reliability Workbook』: https://sre.google/workbook/table-of-contents/
- Qiita Markdown記法チートシート: https://qiita.com/Qiita/items/c686397e4a0f4f11683d