【書評】 SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践

はじめに

『SREの探求』は、SRE（Site Reliability Engineering）をGoogleの外でどう根付かせるかを、約30名の実務者が自分の言葉で語った一冊です。原題は "Seeking SRE" で、編者はDavid N. Blank-Edelman、監訳は山口能迪さん、訳は渡邉了介さん、版元はオライリー・ジャパンです。

Googleの『SRE サイトリライアビリティエンジニアリング』は「Googleではこう運用している」という体系書でした。本書はその続編というより、「Googleではない組織で、人数も文化も違う中でどう適応したか」の事例集という位置づけです。

この記事では、設計・アーキテクチャに関心のあるエンジニア向けに、本書の全体像と私が重要だと感じた論点を整理します。

本記事は私なりの要約と感想です。各章の詳細な事例や数値、図表は書籍本体をご確認ください。

本書の特徴

最大の特徴は、編者が「会話」を軸に編集している点です。各章の文体は統一されておらず、対談形式の章、クラウドソーシングで集めた意見を並べた章、講演を元にした章などが混在しています。

• 著者の所属はNetflix、Dropbox、Spotify、Facebook、Microsoft、LinkedIn、Lyftなど多岐にわたる
• 「正解は一つ」という立場を取らず、意見の食い違いもそのまま載せている
• SREの技術面だけでなく、採用、心理的安全性、メンタルヘルス、倫理まで扱う

読み進めるうちに、SREが単なる運用手法ではなく、組織と人の設計問題であることが見えてきます。

全体構成

部	章	テーマ
第Ⅰ部 SREの導入	1〜13章	組織にSREを入れる方法、採用、メトリクス、大企業での導入、DevOpsとの関係
第Ⅱ部 SREの周辺領域	14〜18章	カオス、プライバシー、データベース、耐久性、機械学習
第Ⅲ部 ベストプラクティスと技術	19〜26章	ドキュメント、教育、SLO、文化、アンチパターン、インフラ技術
第Ⅳ部 SREの人間的側面	27〜32章	心理的安全性、認知的作業、燃え尽き、オンコール、社会運動
まとめ	33章	会話を続けるための呼びかけ

全33章を通読する必要はありません。自分の組織の課題に近い章から読んでも成立する作りです。

第Ⅰ部 SREの導入

コンテキストとコントロール（1章）

Netflix出身のCoburn Watsonさんとの対談です。可用性を高める手段として、罰則や権限剥奪といった「コントロール」ではなく、判断に必要な情報を渡す「コンテキスト」を重視するという考え方が語られます。

印象に残った点は次のとおりです。

• 情報とコンテキストは別物。ダッシュボードを流し続けても、受け手が意味を読み取れなければ無視される
• 悪い判断が起きたとき、まず疑うのは「その人に十分な文脈が渡っていたか」
• 傾向が悪化したときだけ届くスコアカードのように、通知の出し方を設計する
• 自動デプロイの途中に危険な操作を検知して警告する「ガードレール」を、ツール側に埋め込む

一方で、航空機や医療機器のように人命に関わる領域ではコントロール寄りにならざるを得ない、という限界も明示されています。この「どこに落とし所を置くか」という姿勢は、設計判断そのものだと感じました。

SREの採用とチーム作り（2〜3章）

2章はDropboxの経験をもとにした面接設計の話です。ファネルの各段階の目的、暫定の候補者像を先に固める手順、バイアスを減らす工夫などが整理されています。在宅課題を使うならオンサイト面接で足りなかった観点を補う目的に限る、という指摘も実践的です。

3章は「SREチームを作りたい」と考えているリーダー向けの問いかけです。

• 流行っているから、という理由だけでは長続きしない
• 肩書きを付け替えただけの「名前だけのSRE」は機能しない
• SREは開発チームの協力、経営層の後ろ盾、専任の人員がそろって初めて成立する
• SLOやエラーバジェットは、守る側の規律がなければ形骸化する

この章は導入前のチェックリストとして読めます。

メトリクスで改善を回す（4章）

Microsoft Azureの事例です。障害対応の時間を分解して計測する枠組みが紹介されます。

TTD（検出）→ TTE（エンゲージ）→ TTF（修正）
          合計 = TTM（軽減までの総時間）

さらに、主指標を動かすための代理メトリクス、修復アイテムを追跡する「修復負債」、記録されなかった修復を可視化する「仮想修復負債」といった発想が出てきます。

ここで学べるのは、「頑張れ」と言う代わりに、具体的なアクションに落とせる指標を置くことです。ポストモーテムを書いて終わりにせず、修復アイテムが実際にバックログに入ったかまで測る視点は、すぐ真似できると思います。

サードパーティとの協力（5章）

LinkedInやNetflixでの経験を持つ著者が、DNS、CDN、決済、メール、監視といった外部サービスを、SREとしてどう扱うかを論じます。

• 依存先は補助的な存在ではなく、自社の技術スタックの拡張として扱う
• 「構築・購入・採用」の三択で考える。初期費用だけでなく、導入作業や撤退のコストまで見積もる
• ベンダー独自の機能は便利だが、乗り換えにくくなる点に注意する
• ベンダーは完全なブラックボックスではなく、APIやログの提供度合いに幅がある
• 外部サービスのSLIは、合成モニタリングや実ユーザー計測で自分たちの側から確かめる
• テスト、監視、自動化、災害対策、そして関係の終了まで、手順書の対象に含める

特に、「ダウンするより遅いほうがまし」という縮退の考え方と、契約終了の意思を早めに伝えて相手に改善の機会を与える、という人間的な配慮が印象に残りました。

専任チームなしのSRE（6〜7章）

6章はSoundCloud、7章はSpotifyの事例です。どちらも「専任のSRE部門を持たない」状況でSREの原則を適用しています。

• 6章では、少人数の中堅組織だと専任SREの最小規模（オンコールを回せる人数）が組織の大きな割合を占めてしまう点が語られる
• 開発チームにSREを一人ずつ派遣する方法は、影響力を持てずに失敗した
• 代わりに「自分で作って自分で運用する」文化を強め、デプロイ基盤を整え、各チームがオンコールを持つ形へ移行した
• その後、横断支援を担う小さなプロダクションエンジニアリングチームが生まれた。ただし機能リリースを止める権限は持たない
• 7章のSpotifyは、小さな自律チーム（分隊）が運用まで担う「分隊型運用」を採っている

どちらも、SREを役割や部署ではなく「原則の適用」と捉えている点が共通しています。小規模な組織にとっては、最も現実的な参考になる章だと思います。

大企業での導入（8〜10章）

• 8章は、SaaSスタートアップが大企業に買収された後、マトリクス型組織の中でSREを広げた経験談
• 9章は、システム管理者からSREへの視点の切り替えを扱う。システムを「エラーを出さない状態」に保つのではなく、ビジネス上の望ましい状態から定義するという考え方
• 10章は、従来型の運用組織をSREに変えようとする大企業のリーダー向けに、立ちはだかる組織的な障壁を特定する方法を示す

技術よりも組織の慣性との戦いが主題で、「ツールは変えられる、個人のスキルも育てられる、でも組織の仕組みを変えるのが最も険しい」という整理が的確です。

DevOpsとの関係（11〜12章）

11章はGene Kimさんによる、DevOpsの文脈で見たSRE由来のパターンの紹介です。Googleのウェブサーバーチームが自動テストを根付かせた経緯などが語られます。

12章は編者がSNSで募集した意見を並べた「クラウドソーシング章」です。DevOpsとSREの関係について、補完的、包含、対立、同じものの別名など、見解は割れています。編者自身がまとめを付けず、読者に委ねている点が本書らしいところです。

Facebookのプロダクションエンジニアリング（13章）

運用の問題はソフトウェアで解決すべきで、そのソフトウェアを作った人が運用に最も詳しい、という思想が語られます。ソフトウェアエンジニアリングとプロダクションエンジニアリングの評価基準を揃えるといった、組織設計の話も含まれています。

第Ⅱ部 SREの周辺領域

カオスエンジニアリング（14章）

カオスエンジニアリングは、障害を起こすことが目的ではなく、システムに最初から潜んでいる複雑さを実験で露わにする営みだと整理されます。

• 複雑な分散システムでは、従来のテストだけでは信頼感が得られない
• 仮説を立て、本番環境に近い条件で検証する
• ステージングは本番の完全な複製にならないため、本番での検証に意味がある

プライバシーとの接点（15章）

信頼性とプライバシーは、どちらも「ユーザーの期待に応える」という同じ目的を持つ、という切り口です。開発ライフサイクルの早い段階から関与するほど結果が良くなる点も共通しています。SREがプライバシーエンジニアリングを支える立場にいる、という指摘は新鮮でした。

データベースとデータ耐久性（16〜17章）

16章はデータベースリライアビリティエンジニアリングです。データの保護、セルフサービス化、自動化といった原則を、DBAの役割の進化として描いています。

17章はDropboxのデータ耐久性の話です。要点を挙げます。

• レプリケーションは最低保障にすぎない
• バックアップは、リストアに時間がかかる点と鮮度の点に注意が必要
• 検証や分離、保護の仕組みと組み合わせて初めて耐久性になる
• 本当に怖いのは想定済みの障害ではなく、誰も気付かなかった事象（ブラックスワン）

可用性は一時的に落ちても回復できますが、データの喪失は取り返せません。この非対称性を意識した設計が必要だと再認識しました。

機械学習（18章）

アラートのノイズ削減、異常検出、チケット分類、予測といった、SREの運用課題に機械学習を当てる入門です。難しい理論には踏み込まず、「まず試せる」ことを示す内容です。

第Ⅲ部 ベストプラクティスと技術

ドキュメント、教育、SLO（19〜21章）

• 19章：ドキュメントの品質を「構造品質」と「機能品質」に分け、ソフトウェアテストの考え方を借りて開発フローに組み込む
• 20章：ゲーム形式のインシデント訓練や、ポストモーテム輪読会など、能動的な学び方を紹介する
• 21章：SLOを設定する意味と、SLAとの違い。パーセンタイルだけで見るのではなく、目標を満たす利用者の割合で見るという考え方も示される

SLOの章では、他組織のSLOは自分たちには意味がない、という指摘が印象的でした。SLOは期待を言語化する手段であって、借りてくるものではありません。

成功の文化とアンチパターン（22〜23章）

22章は、SREの価値は障害を減らすことだけでなく、ビジネスの成功に集中することにある、というメンタルシフトの話です。

23章は、現場で繰り返し見られる失敗パターンの集成です。冒頭で挙げられる「サイトリライアビリティオペレーション」（看板だけSREに掛け替えた運用）は、導入を検討する組織が最初に避けるべき落とし穴として象徴的です。

インフラ技術（24〜26章）

章	技術	要点
24章	イミュータブルインフラ	変更ではなく交換にすることで、状態管理とトイルを減らす。永続データ層は難しい
25章	スクリプタブルロードバランサー	Luaなどでリクエスト処理を拡張し、小さなチームでも高度な制御を実現する
26章	サービスメッシュ	ネットワーキングと可観測性の共通基盤を提供し、マイクロサービスの運用負荷を下げる

24章には、デメリットとして開発サイクルの遅延やデータ層の扱いも書かれており、技術の売り込みで終わっていないところに好感を持ちました。

第Ⅳ部 SREの人間的側面

この部が本書の個性を最も強く出しています。

心理的安全性（27章）

成功するチームの最も重要な指標は心理的安全性だという調査結果を起点に、失敗した新人が責められる架空の事例で、安全でないチームが個人に与える影響を描いています。「自分が何かをして失敗したら責められる」といった問いで、チームの状態を点検できます。

認知的作業（28章）

インシデント対応は、見た目に反して高度な認知的作業だという内容です。システムに現れる兆候を読み解き、取りうる行動を比較し、意思決定する、といった活動が整理されています。人間の役割を軽視した自動化への警鐘としても読めます。

燃え尽きとオンコール（29〜30章）

• 29章：メンタルヘルスと職場の関係を扱う。SREの慣行は不快な作業を減らす発想に偏りがちだが、すでに症状を抱えて働く人にとっては前提が合わないことがある、という指摘が重要
• 30章：「オンコールをやめるべきだ」という大胆な主張。他職種のオンコールとの比較から、現状の形に代わる選択肢を探る

オンコールを前提にしてきた私たちの常識を疑う章で、同意するかどうかは別にして、一度は読む価値があります。

複雑なシステムと社会運動（31〜32章）

31章は、米国の医療保険サイトの立て直しに関わった経験をもとに、コンピュータのシステムと人間のシステムは分離できないことを語ります。

32章は、社会運動の組織化とSREの方法論の類似点を示し、SLOやインシデント対応のスキルを、社会をより公正にするために使う道を提案します。SLIをあらゆるユーザーの体験を含めて測る、といった具体例も出てきます。

設計者の視点で見た本書の価値

アーキテクチャに関心のあるエンジニアにとって、本書から得られる示唆は次のように整理できます。

1. 信頼性は技術だけで決まらない

SLOや自動化、イミュータブルインフラといった技術要素の前に、責任の所在、文化、評価制度が信頼性を左右します。設計レビューの観点に「組織が運用できる設計か」を加えるべきだと感じました。

2. 規模に合わせて原則を取捨選択する

専任SREを置けない組織でも、原則は適用できます。SoundCloudやSpotifyの事例は、「Googleと同じ形にする」のではなく「自分たちの制約に合わせて原則を再解釈する」姿勢を示しています。

3. 測るものが行動を決める

TTD、TTE、TTFのように時間を分解し、代理メトリクスで行動に落とす4章は、プロダクトの運用設計にそのまま流用できます。何を測るかは、何を改善対象にするかの宣言でもあります。

4. 外部依存も自社の一部として設計する

5章では、DNSやCDNなどのサードパーティを補助的な存在ではなく技術スタックの拡張と捉える考え方が示されます。

• 依存先がダウンすれば自社もダウンする
• 影響が直接か間接かを整理する
• 構築・購入・採用の判断では、移行コストやベンダーロックインまで含めて考える
• 依存先が不調になったときの縮退や撤退も、手順書に含めておく

マイクロサービスやSaaS連携が当たり前になった今、依存関係の設計に直結する内容です。

5. 人間を設計対象に含める

認知的作業、心理的安全性、オンコール負荷は、システム設計の外にある話ではありません。人がシステムの一部として機能する前提で設計を見直す、という視点は、読後に最も長く残りました。

読むときの注意点

• 書かれた時期の都合で、ツールや事例の一部は古くなっている（監訳注で補足されている箇所もある）
• 事例集という性質上、章ごとに主張が食い違う。体系的な答えを求める人は、先にGoogleのSRE本を読んでおくとよい
• 29章は米国の制度を前提としており、日本の状況と異なる部分がある
• 通読すると分量が多いため、最初は目次から気になる章を選ぶ読み方が現実的

どんな人におすすめか

こんな人	特に読むと良い章
SREをこれから導入したい	3章、6章、7章、10章
小規模な組織で運用を改善したい	6章、7章、11章
指標設計やSLOに取り組みたい	4章、21章
外部サービスへの依存が多い	5章
データを扱うシステムを設計している	16章、17章
チームの健全性に課題を感じている	27章、29章、30章

おわりに

『SREの探求』は、SREの手順書ではなく、実務者たちの試行錯誤を横から聞く本です。うまくいった話だけでなく、失敗した派遣モデルや、意見が割れたままの議論も含まれているので、自分の組織に当てはめて考える材料になります。

読後に私が持ち帰ったのは、「信頼性は、技術と人と組織の三つを同時に設計して初めて成立する」という認識です。設計やアーキテクチャに関心のある方ほど、第Ⅰ部と第Ⅳ部を併せて読むことをおすすめします。

書誌情報

• 書名：SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践
• 編者：David N. Blank-Edelman
• 監訳：山口 能迪
• 訳：渡邉 了介
• 発行：オライリー・ジャパン（2021年9月）
• ISBN：978-4-87311-961-8