技術評論社から 2025 年 9 月に SRE の入門書が発売されていて、ちょうど SRE を体系的にキャッチアップしたいと思っていたタイミングだったので、kindle 版を購入してみました。原典とされる『SRE サイトリライアビリティエンジニアリング』は内容が重そうで、日本語版の出版も 2017 年なので今との差分がありそうだと感じ、最初の一冊としては躊躇していたためです。
https://www.amazon.co.jp/dp/B0FN2KWBBN
本書は日本で SRE を実践している 7 名による共著で、章ごとに担当が分かれています（SRE NEXT や SRE Lounge のコアメンバーが多い顔ぶれです）。構成は SRE の概要（1 章）、主要なプラクティス（2〜7 章）、組織と実践（8〜9 章）となっています。書名のとおり「知識地図」なので個々のトピックの解説は浅めですが、著者の経験談や具体例が豊富な章もあり、各所で参考図書も紹介されています。SRE の全体像と用語をひととおり掴んだうえで、深掘りの入り口を探したいという段階の人に向いていると思います。
読む順番は、まずは 1・8・9 章で SRE の輪郭を押さえ、そのあと 2〜7 章の各論に進むとよさそうだと思いました。具体的には、1 章で SRE の概要を掴んだあと、9 章に進んで「9.2 実践のコツ」と「9.4 Platform Engineering / DevOps との違い」を読み、8 章の組織構造でチームに組み込むパターンを学んで、最後に 9 章に戻って「9.1 実践事例」と進むと、SRE が組織のなかでどう機能するのかのイメージが早く固まると思います。
前提知識としては、一般的なソフトウェア開発や運用業務を理解しているほうが読みやすいと思います。CI/CD や IaC とはこういうもの、といった説明はありません。また SRE × AI の話題は扱われていません。2026 年現在、SRE 業務は AI との協業により大きく変わりそうなので、その部分はキャッチアップできず残念でした。
以下、各章でどんな学びがあったかまとめています。また、より詳細な章立ては こちら から確認することができます。
１．SRE とは
SRE の定義から入り、それを「サイト」「信頼性」「制御する」といった要素に分解していく章です。なかでも「制御する」の説明が本質だと感じました。信頼性を高めるだけならシステムを塩漬けにするのが最も確実ですが、それではビジネス価値が落ちてしまいます。ユーザーが求めているのは落ちないシステムではなく魅力的で落ちないシステムだ、という整理で、信頼性は高すぎても低すぎてもいけないという位置づけがわかりやすく示されます。
一方で「ソフトウェアエンジニアリングの原則と手法」が何を指すのかは、本書の記述だけでははっきりしませんでした。腑に落ちなかったので生成 AI に補ってもらったところ、従来のシステム管理は手順書を見ながらの手作業が一般的で、そこに自動化やコード管理、テストといった開発のエッセンスを持ち込もうという話だ、という説明が返ってきました。なお Google の SRE Book は全文が公開されています。
２．信頼性を定義して組織で運用する
SLO が信頼性の目標値（社内向け）、SLA が合意値（社外向け）、SLI がそれらに使う指標、エラーバジェットが SLO の許容範囲、という 4 要素の整理から、SLO の導入ステップまでを扱う章です。よく知られた内容も多く、SRE の基本（2021 年版）: SLI、SLA、SLO の比較 でも同じ整理を読むことができます。
納得感があったのは、SLO をビジネスの成長と信頼性向上のバランスをとる指標として位置づけている点です。エラーバジェットから月間で許容される停止時間が算出でき、その数字によってインフラ構成やデプロイ戦略まで変わってくる、という説明も印象に残りました（Error Budget Policy）。著者の経験では経営陣を含めた合意形成が最も重要とのことで、コラムには週次・月次レビューの進行例まで載っています。欲を言えば、モデルシナリオで SLO を設定するまでロールプレイする例もあるとよかったと思います。
３．システムの状態を観測する
モニタリング（異常の検知）とオブザーバビリティ（原因の分析）の違いから入り、Four Golden Signals のような定番の監視項目、アラート通知の設計、ツールの選定までを扱う章です。本書には出てこない整理ですが、モニタリングは What を検知するアプローチ、オブザーバビリティは Why を特定する能力、という説明もよく見かけます。
個人的な収穫は、オブザーバビリティのシグナルがログ・メトリクス・トレースの 3 つではなく、プロファイルとダンプを加えた 5 つとして紹介されていたことです。この整理は CNCF の Observability Whitepaper に基づくもので、そちらでも 3 つを「3 本柱」ではなく primary signals と呼び、継続的プロファイリングやクラッシュダンプが後発のシグナルとして加わってきた、と説明されています。
４．障害を学びにつなげる
ポストモーテムの章です。準備・実施・共有の 3 段階からなるフレームワークが示されています。個人的に大事だと感じたのは、準備段階の「目的の明確化」、つまり責任追及ではなく教訓を得ることが主題だと最初に強調しておく点でした。
この章で最もよかったのは、悪いポストモーテムと良いポストモーテムを具体例で対比している節です。抽象的な原則だけでなく実物のイメージが提示されるので、自分のチームでやるとしたらどうなるかを考えやすくなります。さらに、本物のインシデント後にいきなり初めてのポストモーテムを実施してもうまくいかないという前提で、ワークショップの構成例まで提案されています。こうしたサンプルで見せてくれる書き方は他の章にも欲しかったところです（Postmortem Culture: Learning from Failure）。
５．障害対応のプロセスや体制を作る
オンコールの章です。勤務時間外でも緊急時の対応要員として待機する体制であり、担当者に強いストレスを与えるものなので、仕組みづくりと文化づくりが重要だという立場で一貫しています。シフト設計、Runbook、トレーニング、手当、燃え尽き、心理的・身体的ケアと続き、技術よりも人と組織の話が中心です。SRE を担当者の消耗の上に成り立たせないための章だと理解しました（Being On-Call）。
ツールとしては PagerDuty や Opsgenie が挙げられていますが、Opsgenie は Atlassian が 2025 年 6 月に新規販売を終了し、2027 年 4 月にサポート終了を予定しています（Schedule an Opsgenie migration）。本書の発売とほぼ同時期のアナウンスなので、これから選定するなら注意が必要です。
６．手作業を自動化し効率化する
トイルの章です。運用業務をトイル、オーバーヘッド、システムエンジニアリング、ソフトウェアエンジニアリングの 4 つに分類し、前者 2 つを業務の 50% 以下に抑えることが目標とされています。管理の手順は分類と計測、目標設定、実施、効果測定という流れで、実施の選択肢に「そのタスクをもうやめる」が含まれているのは実務的だと思いました。
後者 2 つの違いがよくわからなかったので AI に聞いてみたところ、システムエンジニアリングを「今あるシステム」に限定されたもの、ソフトウェアエンジニアリングを「未来のシステム」にも適用できるものと解釈すれば本書の言い回しとも整合する、という回答でした。章としてはコンパクトで著者独自の見解は薄めですが、トイルは SRE の文脈で最も引用される概念のひとつなので、堅実にまとめてあること自体に価値があるとも言えます（Eliminating Toil）。
７．サービスのリリースを事前にレビューする
プロダクションレディネスレビュー（PRR）の章です。重要な変更を本番環境にリリースする前に、その変更が本番運用の条件を満たしているかを確認するプロセスと定義され、すべてのリリースを対象にするものではないと釘が刺されています（The Evolving SRE Engagement Model）。
引っかかったのは、一般的なリリース前レビューと何が違うのかがあまり強調されていない点です。AI に聞いたところ、目的が機能の確認ではなく運用責任の移管であること、評価軸がビジネス要件ではなく運用性やレジリエンスであること、という整理が返ってきました。初学者が最初に知りたい部分なので、もう少し前面に出ていてもよかったと思います。
事例としては GitLab の PRR ハンドブック が紹介されます。日本企業の例も調べてみたところ、タイミー、Mackerel、スタディサプリ の記事が見つかり、チェックリストを開発者が非同期で埋め、SRE が非同期でレビューする進め方がメジャーだと理解しました。
８．SRE の組織構造
SRE をどう組織に組み込むかの章です。『チームトポロジー』の枠組みを使った 3 つの型、小規模・中規模・大規模に対応させた 3 つの組織パターン、そして Product SRE や Platform SRE といった実装モデルと、それを選ぶための選択ツリーが順に示されます。
正直なところ、この章は 3 つの節（8.2〜8.4）がそれぞれ別の言葉で似たようなことを説明している印象があり、相互の対応関係が掴みきれませんでした。いちばん平易で組織規模との対応も明示されているのは「8.3 組織パターン」の節で、私にはここが最もわかりやすかったのですが、選択ツリーが用意されているのは「8.4 実装モデル」の分類だけなので、著者の本命はそちらなのかもしれません。1 章で概要を掴んだあとに通読し、いちばんしっくりきた節をしっかり読む、という進め方でよいと思います。
９．SRE の実践
実践編です。著者が過去に経験した組織での実践事例、SRE の実践のコツ、Platform Engineering や DevOps との違いが扱われます。実践事例では 8 章の分類が実際に使われるので、前章で掴みきれなかった対応関係を具体化するのに役立ちました。
「9.2 実践のコツ」がこの章で最も実用的な部分でした。短期間で成果が出るものから着手する、現場がいま困っていることからニーズを把握する、日次から週次で定例に参加する、といった内容で、SRE を導入する側の目線で並べ直されていることに意味があると感じました。
9.4 節での近接領域との違いについては、DevOps が抽象的な文化であり、SRE が具体的な手法である、という整理が納得しやすかったです。本書では紹介されていませんが、この関係を表す言い回しとして個人的に好きなのは「class SRE implements interface DevOps」という表現です（How SRE Relates to DevOps）。
おわりに
書名のとおり、SRE という領域の輪郭と用語を一冊で見渡せるようにしてくれる本でした。個々のトピックは検索でも届く一般論が多いのですが、4 章のように著者の経験やサンプルシナリオが効いている章もあり、そこが読みどころだと思います。一方で、8 章の分類の対応関係が掴みにくい点、SRE と AI の関係に触れられていない点は物足りなく感じました。AI との関わりについては出版年を考えれば妥当ではあるのですが、期待していた部分ではあります。
原典が重そうで手が出せずにいた身としては、先に地図を手に入れてから原典に向かうという順序は正解でした。次は『SRE サイトリライアビリティエンジニアリング』に進むつもりですが、8 章で前提知識の不足を感じた『チームトポロジー』も候補に入れておこうと思います。
コメント