目的地
「オブザーバビリティ・エンジニアリング」に至る道筋
この本にたどり着くために、先に読んでおきたい本を依存関係から逆算しました。基礎から順に並んでいます。
ここまでの道筋（10冊）
なぜ先に読むのか: Poulton『Docker Deep Dive』で単一コンテナの作成・実行を理解したら、本番では多数のコンテナをどう協調動作させるかが課題になる。Lukša『Kubernetes in Action』はコンテナオーケストレーションの仕組みを基礎から解説し、1台のコンテナから分散運用へスケールさせる。
なぜ先に読むのか: Kubernetes の基本的な使い方を習得したら、その上で繰り返し現れる設計問題への定石を学ぶ段階。Ibryam & Huß『Kubernetes Patterns』はサイドカーやヘルスチェックなど、クラウドネイティブアプリを K8s 上で正しく設計するためのパターン言語を提供する。
なぜ先に読むのか: 『Kubernetes Patterns』でアプリを K8s 上で正しく設計する型を学んだら、それを本番で運用し続ける現場知へ。『クラウドネイティブDevOps with Kubernetes』は設計パターンを実際の運用（監視・スケーリング・障害対応）へ接続し、設計と運用のギャップを埋める。
なぜ先に読むのか: K8s 上の多数のマイクロサービスを運用すると、従来の監視では「どこで何が起きたか」を追いきれなくなる。『オブザーバビリティ・エンジニアリング』は分散トレースや構造化イベントで分散システムの内部状態を可視化し、クラウドネイティブ運用に必須の観測能力を与える。
なぜ先に読むのか: Julian『入門 監視』で「あらかじめ決めた指標を見張る」監視を設計できたら、次は未知の障害も探索的に調べられるオブザーバビリティへ。Majors ら『オブザーバビリティ・エンジニアリング』は高カーディナリティなイベントで「なぜ起きたか」を後から問える系を説き、監視の限界を超える。
なぜ先に読むのか: Nygard『Release It!』でサーキットブレーカー等の安定性パターンを実装したら、それらが本番で実際に効いているかを観測する必要がある。『オブザーバビリティ・エンジニアリング』はパターンの発動状況やシステムの内部挙動を可視化し、「壊れない設計」が機能していることを検証可能にする。
なぜ先に読むのか: 『The Phoenix Project』は IT 運用の混乱を小説仕立てで追体験させ、なぜ DevOps が必要かを腹落ちさせる導入書。問題意識を得たら、同じ Gene Kim らによる『The DevOps ハンドブック』でその解決策を体系的な実践技法として学ぶのが王道の流れ。
なぜ先に読むのか: 『The DevOps ハンドブック』が開発と運用の協調を説くのに対し、Google『SRE サイトリライアビリティエンジニアリング』はその運用側を「ソフトウェアエンジニアリングで解く」具体形を示す。エラーバジェットや SLO によって信頼性を工学的に管理する、DevOps の自然な発展先。
なぜ先に読むのか: 『SRE サイトリライアビリティエンジニアリング』が Google の実践から抽出した原則を語るのに対し、続編『サイトリライアビリティワークブック』は「自社でどう実装するか」を具体的な手順とケーススタディで示す。理論を読んだら実装編へ、が必須（required）の流れ。
なぜ先に読むのか: 『サイトリライアビリティワークブック』で SLO を運用に乗せると、SLI を正確に計測し違反の原因を追跡する基盤が要る。『オブザーバビリティ・エンジニアリング』はその計測・調査基盤を与え、SLO ベースの運用を支える観測のインフラを具体化する。