# SREの探求 ## 概要 『SREの探求』(原書 *Seeking SRE: Conversations About Running Production Systems at Scale*)は、[[David N. Blank-Edelman]] が編者として 30 名超の実務者の寄稿・対談を集めた SRE の論集である。Google が [[SRE Book]] で確立した方法論を、Google 以外の企業・組織がどう解釈し、どう導入に失敗し、どう定着させたかという**現場の証言**を主題とする。単一組織の規範を示す SRE Book に対し、本書は「SRE とは何であってよいのか」を複数の声で問い直す位置にある。 ## 書誌情報 - **書名**: SREの探求 — 様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践 - **原書**: *Seeking SRE: Conversations About Running Production Systems at Scale*(O'Reilly Media, 2018) - **編者**: David N. Blank-Edelman - **監訳**: 山口 能迪 - **訳**: 渡邉 了介 - **出版社**: オライリー・ジャパン(発売: オーム社) - **発行日**: 2021 年 9 月 1 日(初版第 1 刷) - **ISBN**: 978-4-87311-961-8 - **構成**: 全 4 部 33 章 + 前付「はじめに」 ## 構成と主要テーマ 全 33 章を 4 部に分ける。寄稿者は 40 名近くに及び、対談・アンケート・書籍からの抜粋など形式も一定しない。編者はこの非均質さを意図的に選んでいる。 → [[@2021__OReillyJapan__SREの探求 - Preface はじめに]] — 編者が「会話(conversations)」「探求(Seeking)」を核心語に、[[SRE Book]] とは異なる非均質な会話集としての編集方針と本書誕生の経緯を語る序文。 ### 第 I 部: SREの導入(第 1〜13 章) Google 以外の組織が SRE をどう導入し、どこで失敗したかの実例集。専任チームの有無・組織規模・レガシーの有無という条件の違いが、そのまま導入経路の違いとして現れる。 → [[@2021__OReillyJapan__SREの探求 - Chapter 1 SREにおけるコンテキストとコントロール]] — Netflix の Coburn Watson が、意思決定の責任とともに情報を渡す「コンテキスト駆動型」と、プロセス・権限制限で結果を強制する「コントロールベース」の対比を語る対談。 → [[@2021__OReillyJapan__SREの探求 - Chapter 2 サイトリライアビリティエンジニアの面接]] — Dropbox の Andrew Fong が、11 段階の採用ファネルと 3 段階の面接設計、バイアス対策を体系化する。 → [[@2021__OReillyJapan__SREの探求 - Chapter 3 なるほど、SREチームを作りたいのですね]] — Google の Luke Stone が、100 人超のリーダーとの面談経験から「名前だけの SRE」を避け、組織が SRE にふさわしいかを判断する問いを示す。 → [[@2021__OReillyJapan__SREの探求 - Chapter 4 インシデントのメトリクスを用いたSREの大規模な改善]] — Microsoft Azure の Martin Check が TTD/TTE/TTF/TTM・代理メトリクス・修復負債で信頼性投資を優先順位づけしたケーススタディ。 → [[@2021__OReillyJapan__SREの探求 - Chapter 5 サードパーティとの協力を円滑に進める重要性]] — Jonathan Mercereau が、サードパーティを自社の拡張として扱い、CapEx/OpEx/PrOpEx/AbEx で構築・購入・採用を評価する実務を示す。 → [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] — SoundCloud が専任 SRE チームと SRE 派遣の両方に失敗した後、you build it you run it と共通デプロイ基盤(Bazooka)で分散適用へ至った経緯。 → [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]] — Spotify が専任 SRE チームを持たないまま、オンコールと運用責任を開発チームへ引き渡す「分隊型運用(Ops-in-Squads)」へ移行した記録。 → [[@2021__OReillyJapan__SREの探求 - Chapter 8 大企業におけるSREの導入]] — 1930 年代創業の大企業 Agilent に、買収された SaaS スタートアップ側から SRE を導入した 5 ステップの実践記録。 → [[@2021__OReillyJapan__SREの探求 - Chapter 9 25ページでシステム管理者からSREへ]] — Amazon Japan の Vladimir Legeza が、コンポーネント別 SLA と日次可用性計算を通じて、システム管理者から SRE への視点転換を 11 ステップで示す。 → [[@2021__OReillyJapan__SREの探求 - Chapter 10 大企業でSRE導入の道を開く方法]] — Damon Edwards が、トイル・サイロ・引き継ぎ・キューという構造的病理を分析し、「サービスとしての運用(OaaS)」という設計パターンを提示する。 → [[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]] — Gene Kim が *The DevOps Handbook* から、GWS の自動化テスト文化・LRR/HRR・単一共有リポジトリを、SRE 由来で DevOps 全般に通じるパターンとして示す。 → [[@2021__OReillyJapan__SREの探求 - Chapter 12 DevOpsとSRE：コミュニティからの声]] — 編者が 34 か国 1,165 人に問うたアンケートから、DevOps と SRE の関係が単一の結論に収斂せず 7 つの説明軸が並立することを示す。 → [[@2021__OReillyJapan__SREの探求 - Chapter 13 Facebookにおけるプロダクションエンジニアリング]] — Facebook の Pedro Canahuati が、SRE → SRO+AppOps → PE という 4 年の組織変革と、集中型報告+分散型配属の PE 職種を語る対談。 ### 第 II 部: SREの周辺領域(第 14〜18 章) 信頼性の隣接領域 — カオスエンジニアリング、プライバシー、データベース、耐久性、機械学習 — が SRE とどう交わるか。 → [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] — 元 Netflix の Casey Rosenthal が Chaos Monkey/Chaos Kong の導入経緯と PrinciplesofChaos.org の 4 手順・5 原則を当事者として記す。 → [[@2021__OReillyJapan__SREの探求 - Chapter 15 信頼性とプライバシーが交わるところ]] — Betsy Beyer と Amber Yust が、信頼性とプライバシーの共通目標と、プライバシー障害が不可逆であることに由来する非対称性を論じる。 → [[@2021__OReillyJapan__SREの探求 - Chapter 16 データベースリライアビリティエンジニアリング]] — Laine Campbell が原著 *Database Reliability Engineering* から、DBA の番人モデルを「データの保護・セルフサービス・データベースは特別ではない」で再定義する。 → [[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]] — Dropbox の James Cowling が、可用性から独立した耐久性を、マルコフモデルと分離・保護・検証・自動化の 4 本柱で論じる。 → [[@2021__OReillyJapan__SREの探求 - Chapter 18 SREのための機械学習入門]] — Acquia の Ricardo Amaro が、機械学習のカテゴリからニューラルネットワーク・Jupyter/TensorFlow の実践、DeepMind の省電力事例までを SRE 実務者向けに解説する入門編。 ### 第 III 部: SREのベストプラクティスと技術(第 19〜26 章) ドキュメント・教育・SLO といった実務の型から、ロードバランサー・サービスメッシュ・イミュータブルインフラという技術選択まで。 → [[@2021__OReillyJapan__SREの探求 - Chapter 19 ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合]] — Google の Ríona MacNamara らが、g3doc/EngPlay でドキュメントをコードと同じワークフローへ統合し、機能品質を優先した取り組みを示す。 → [[@2021__OReillyJapan__SREの探求 - Chapter 20 アクティブなティーチングとラーニング]] — Google の Laura Nolan が、Wheel of Misfortune・Incident Manager カードゲーム・SRE Classroom という 3 種の能動的学習の教材を示す。 → [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] — Circonus の Theo Schlossnagle が、SLA/SLO の区別と可用性計測の 3 方式に、PDF/CDF/ヒストグラムによる分布分析を接続する。 → [[@2021__OReillyJapan__SREの探求 - Chapter 22 成功の文化としてのSRE]] — LinkedIn の Kurt Andersen が、SRE をビジネスの成功実現に集中する活動として捉え直し、4 つの文化的価値と 4 段階の実施フェーズを示す。 → [[@2021__OReillyJapan__SREの探求 - Chapter 23 SREのアンチパターン]] — Dropbox の Blake Bisset が、SRE 業界が繰り返し陥る 18 個のアンチパターンを、名前・症状・処方箋の共通形式で列挙する。 → [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] — 元 Netflix の Jonah Horowitz が、イミュータブルインフラの利点と、収束型設定管理の放棄・永続データ層の困難という代償を論じる。 → [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]] — 元 Shopify の Emil Stolarsky が、Lua 等でスクリプトを書けるロードバランサーがシャード対応ルーティング・無停止デプロイ・スロットリングを可能にすることを示す。 → [[@2021__OReillyJapan__SREの探求 - Chapter 26 サービスメッシュはマイクロサービスの世話人か]] — Lyft の Matt Klein が、サイドカー型サービスメッシュがマイクロサービスの「世話人」たりうるかを、メリットと残存コストの両面から検討する。 ### 第 IV 部: SREの人間的側面(第 27〜33 章) 本書が最も独自性を持つ部。心理的安全性・認知的作業・燃え尽き・オンコールの是非・複雑さ・社会運動と、対象が個人から社会へ広がっていく。 → [[@2021__OReillyJapan__SREの探求 - Chapter 27 SREにおける心理的安全性]] — Facebook の John Looney が、Project Aristotle と架空の新入社員の物語から、SRE が構造的に心理的安全性を損ないやすい 6 要因を論じる。 → [[@2021__OReillyJapan__SREの探求 - Chapter 28 SREの認知的作業]] — John Allspaw と Richard Cook が、SRE の日常業務を「表現線」「共同認知システム」「犠牲を伴う意思決定」という安全科学の概念で分析する。 → [[@2021__OReillyJapan__SREの探求 - Chapter 29 燃え尽きを超えて]] — Quantopian の James Meickle が、燃え尽きと精神疾患・神経発達障害を区別し、インクルージョンの欠如を組織の構造的責任として捉え直す。 → [[@2021__OReillyJapan__SREの探求 - Chapter 30 オンコール反対論]] — Niall Murphy が、オンコールの唯一正当な理由を「プロダクションの知恵」に絞り込み、業界規模の標準化による根本解決を提唱する。 → [[@2021__OReillyJapan__SREの探求 - Chapter 31 複雑なシステムのためのエレジー]] — 元 USDS の Mikey Dickerson が、コンウェイの法則・デコヒーレンス・昇進インセンティブなど 5 つの切り口から、複雑システムに共通する挙動を整理する。 → [[@2021__OReillyJapan__SREの探求 - Chapter 32 運用と社会運動が交わるところ]] — Emily Gorcenski と Liz Fong-Jones が、SRE のスキルを社会運動の組織化に類比し、セントポール原則とインシデント管理原則を対応づける。 → [[@2021__OReillyJapan__SREの探求 - Chapter 33 まとめ]] — 編者が本書を終幕でなく一時休止と位置づけ、Preface の核心語「会話」に回帰して締めくくる。 ## 影響と位置づけ [[SRE Book]] が単一組織の実践を統一理論として提示したのに対し、本書は**意図的に非均質な会話の集積**として編まれている。編者は Preface で「会話(conversations)」を原書タイトル中で最も重要な語とし、33 章の末尾でも同じ語に回帰する。したがって本書から単一の「正しい SRE」を取り出そうとする読み方は、編集意図に反する。 本書の史料的価値は、**同じ問いに対して条件の異なる組織が別々の答えに到達した経路が、一次資料として並んでいる**点にある。専任 SRE チームを持たない組織だけでも、SoundCloud(専任 → 派遣の 2 段階失敗を経て分散適用)・Spotify(常駐 → 集中 → 分散の漸進的自己認識)・Facebook(独立組織 + Embedded の PE 職種)と経路が異なり、レガシー大企業 Agilent の計画的トップダウン導入がさらに対照をなす。 同時に、本書は SRE の前提そのものを疑う章を含む。30 章は [[SRE Book]] 第 11 章(オンコールを前提に最適化する立場)の共同編者である Niall Murphy 自身が、5 年後にオンコールという慣行の是非を問い直したものである。23 章の 18 個のアンチパターン、12 章の「DevOps と SRE の関係は未解決」という編者の立場も同様に、規範の提示ではなく問いの提示に向かっている。 ## 関連 - 書籍: [[SRE Book]] / [[SRE Workbook]] / [[SREをはじめよう]] / [[SREエンタープライズロードマップ]] / [[SLO サービスレベル目標]] / [[The DevOps Handbook]] - 人物: [[David N. Blank-Edelman]](編者) / [[Niall Murphy]] / [[Betsy Beyer]] / [[John Allspaw]] / [[Richard I. Cook]] / [[Casey Rosenthal]] / [[Matt Klein]] / [[Gene Kim]] - 概念: [[SRE]] / [[SRE文化]] / [[SRE組織変革]] / [[SREエンゲージメントモデル]] / [[カーゴカルトSRE]] / [[SREアンチパターン]] / [[DevOpsとSREの関係]] / [[オンコール]] / [[心理的安全性]] / [[表現線]] ## 出典 - David N. Blank-Edelman(編), 山口 能迪(監訳), 渡邉 了介(訳), 『SREの探求』, オライリー・ジャパン, 2021.