Domain
DevOps / SRE
DevOps 文化・継続的デリバリー・SRE・オブザーバビリティ・コンテナ・IaC までを 物語から実装まで段階的に学ぶ学習パス。組織・プロセス・技術の3軸を往復しながら、 高い信頼性と俊敏性を両立するモダンな運用を身につける。
この分野の地形
DevOps / SRE の地形は、なだらかな「文化と計測の高原」から登り始め、 技術的な主稜線を越えて、運用の広野へと至る大陸として描ける。 出発点の高原は、技術以前の「なぜ・どう測るか」の土台。物語で問題意識を得て、 実践の地図を手にし、継続的デリバリーの尾根道へと標高を上げる。
高原の先には「コンテナとオーケストレーション」の山脈が連なる。 最も標高の高い技術的主稜線であり、コンテナという麓のベースキャンプから Kubernetes の主峰へと登攀する。そこからパターン・分散設計・IaC・GitOps へと 稜線が枝分かれし、宣言的に山を動かす技術が広がる。
山を越えた先には「信頼性と観測」の広野が広がる。SRE という運用思想を中核に、 回復性設計・セキュリティとの統合・監視からオブザーバビリティへと地形が続く。 この分野を俯瞰する鍵は、組織・プロセス・技術の3軸を往復しながら、 「速さ」と「壊れにくさ」を同時に登っていく点にある。
矢印の向きに読み進めます／実線＝必須・破線＝推奨
この地図を共有
グループ化
難易度
難易度
依存関係
グラフを計算中...
収録書籍
22件
Docker Deep Dive
Nigel Poulton
入門 監視
モダンなモニタリングのためのデザインパターン
Mike Julian
The DevOps 逆転だ！究極の勝利へ導く3つの道
Phoenixプロジェクト
Gene Kim, Kevin Behr, George Spafford
The DevOps 勝利をつかめ！
Unicornプロジェクト
Gene Kim
LeanとDevOpsの科学[Accelerate]
テクノロジーの戦略的活用が組織変革を加速する
Nicole Forsgren, Jez Humble, Gene Kim
クラウドネイティブDevOps with Kubernetes
ビルド、デプロイ、運用のベストプラクティス
John Arundel, Justin Domingus
Designing Distributed Systems
Patterns and Paradigms for Scalable, Reliable Services
Brendan Burns
The DevOps ハンドブック
理論・原則・実践のすべて
Gene Kim, Jez Humble, Patrick Debois, John Willis
GitOps and Kubernetes
Continuous Deployment with Argo CD, Jenkins X, and Flux
Billy Yuen, Alexander Matyushentsev, Todd Ekenstam, Jesse Suen
Infrastructure as Code
クラウドにおけるサーバー管理の原則とパターン
Kief Morris
Kubernetes in Action
Kubernetesの実用ガイド
Marko Lukša
Platform Engineering
A Guide for Technical, Product, and People Leaders
Camille Fournier, Ian Nowland
チームトポロジー
価値あるソフトウェアをすばやく届ける適応型組織設計
Matthew Skelton, Manuel Pais
Terraform: Up & Running
Writing Infrastructure as Code (3rd ed.)
Yevgeniy Brikman
Building Secure and Reliable Systems
Best Practices for Designing, Implementing, and Maintaining Systems
Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea, Adam Stubblefield
継続的デリバリー
信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化
Jez Humble, David Farley
Kubernetes Patterns
Reusable Elements for Designing Cloud Native Applications (2nd ed.)
Bilgin Ibryam, Roland Huß
オブザーバビリティ・エンジニアリング
分散システムの信頼性とパフォーマンス
Charity Majors, Liz Fong-Jones, George Miranda
Release It!
本番用ソフトウェア製品の設計とデプロイのために 第2版
Michael T. Nygard
Seeking SRE
Conversations About Running Production Systems at Scale
David N. Blank-Edelman
SRE サイトリライアビリティエンジニアリング
Googleの信頼性を支えるエンジニアリングチーム
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy
サイトリライアビリティワークブック
SREの実践方法
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, Stephen Thorne
依存関係
理由: 『The Phoenix Project』は IT 運用の混乱を小説仕立てで追体験させ、なぜ DevOps が必要かを腹落ちさせる導入書。問題意識を得たら、同じ Gene Kim らによる『The DevOps ハンドブック』でその解決策を体系的な実践技法として学ぶのが王道の流れ。
理由: 運用部門の視点で描かれた『The Phoenix Project』に対し、続編『The Unicorn Project』は同じ事件を開発者の視点から描く。物語を気に入った人が、開発生産性や技術的卓越性というもう一つの切り口を楽しみながら掘り下げられる姉妹編。
理由: 『The Unicorn Project』で開発者視点の課題感を掴んだら、それを具体的なプラクティスへ翻訳する段階。『The DevOps ハンドブック』はデプロイ自動化からフィードバックループまでの技法を網羅し、物語で得た問題意識を実装可能な手順に変える。
理由: 『The DevOps ハンドブック』が広範な DevOps プラクティスを概観するのに対し、Humble & Farley『継続的デリバリー』はその中核であるデプロイパイプライン構築を原典として深掘りする。実践の全体像を掴んだ後、CI/CD の理論的支柱を固めるのに最適。
理由: プラクティスを導入したら「本当に効果が出ているか」を計測したくなる。『LeanとDevOpsの科学[Accelerate]』は DORA 研究に基づき、デプロイ頻度・リードタイム・変更失敗率・復旧時間という4指標で組織のパフォーマンスを定量化する科学的根拠を与える。
理由: 『継続的デリバリー』でデプロイパイプラインを構築できるようになったら、その成果を測る物差しが要る。『Accelerate』は CD のケイパビリティが組織パフォーマンスを統計的に予測することを示し、技術投資を経営指標へ接続する論拠になる。
理由: DevOps を技術プラクティスとして導入しても、組織構造が縦割りのままでは速い流れは生まれない。Skelton & Pais『チームトポロジー』は4つのチームタイプとインタラクションモードでコンウェイの法則を逆手に取る組織設計を示し、技術と組織の両輪を揃える。
理由: 『Accelerate』が示す「疎結合なアーキテクチャと自律的なチームが高パフォーマンスを生む」というエビデンスは、具体的な組織設計論を求めさせる。『チームトポロジー』はそのエビデンスを実装する組織パターンを提供し、データに基づくチーム編成の指針になる。
理由: 継続的デリバリーのパイプラインを安定して回すには、アプリだけでなくインフラも再現可能でなければならない。Kief Morris『Infrastructure as Code』はサーバーやネットワークをコードで定義し、バージョン管理・テスト・自動適用する原則を体系化し、CD の前提となる環境の一貫性を担保する。
理由: IaC の原則を理解したら、それを実現する具体的なツールへ。Brikman『Terraform: Up & Running』は宣言的にクラウド資源を定義する Terraform をハンズオンで解説し、抽象的な IaC 原則を実際に動く構成コードへ落とし込む。
理由: Poulton『Docker Deep Dive』で単一コンテナの作成・実行を理解したら、本番では多数のコンテナをどう協調動作させるかが課題になる。Lukša『Kubernetes in Action』はコンテナオーケストレーションの仕組みを基礎から解説し、1台のコンテナから分散運用へスケールさせる。
理由: Kubernetes の基本的な使い方を習得したら、その上で繰り返し現れる設計問題への定石を学ぶ段階。Ibryam & Huß『Kubernetes Patterns』はサイドカーやヘルスチェックなど、クラウドネイティブアプリを K8s 上で正しく設計するためのパターン言語を提供する。
理由: 『Kubernetes in Action』で K8s の仕組みを理解したら、それを本番でどう運用するかという実務へ。Arundel & Domingus『クラウドネイティブDevOps with Kubernetes』はデプロイ・監視・セキュリティ・コスト管理まで、K8s を運用する現場の知恵を体系化する。
理由: 継続的デリバリーの原則を K8s 環境で実現したい人向けの分岐。『クラウドネイティブDevOps with Kubernetes』は K8s 上でのデプロイ戦略やパイプライン構築を扱い、汎用的な CD の知識を Kubernetes ネイティブな運用パターンへ具体化する。
理由: Terraform でクラスタ基盤をプロビジョニングできるようになったら、その上で動くワークロードの運用へ進む。『クラウドネイティブDevOps with Kubernetes』は IaC で用意した K8s クラスタを実際に運用する層の知識を補い、構築から運用までを地続きにする。
理由: Julian『入門 監視』で「あらかじめ決めた指標を見張る」監視を設計できたら、次は未知の障害も探索的に調べられるオブザーバビリティへ。Majors ら『オブザーバビリティ・エンジニアリング』は高カーディナリティなイベントで「なぜ起きたか」を後から問える系を説き、監視の限界を超える。
理由: 『The DevOps ハンドブック』が開発と運用の協調を説くのに対し、Google『SRE サイトリライアビリティエンジニアリング』はその運用側を「ソフトウェアエンジニアリングで解く」具体形を示す。エラーバジェットや SLO によって信頼性を工学的に管理する、DevOps の自然な発展先。
理由: 『入門 監視』で「何を計測するか」を設計できたら、その指標を組織の意思決定に結びつける思想へ。Google『SRE サイトリライアビリティエンジニアリング』は SLI/SLO/エラーバジェットによって監視データを「いつ機能開発を止め信頼性に投資するか」の判断基準へ昇華させる。
理由: 『SRE サイトリライアビリティエンジニアリング』が Google の実践から抽出した原則を語るのに対し、続編『サイトリライアビリティワークブック』は「自社でどう実装するか」を具体的な手順とケーススタディで示す。理論を読んだら実装編へ、が必須（required）の流れ。
理由: Google 発の SRE 理論を学んだら、それが他社でどう翻案・実践されているかを知りたくなる。Blank-Edelman 編『Seeking SRE』は多数の実務者による寄稿集で、Google 以外の文脈における SRE の多様な適用例を提供し、原則の応用範囲を広げる。
理由: 『サイトリライアビリティワークブック』で SRE の実装手順を押さえたら、さらに多様な現場の声を『Seeking SRE』で集める。ワークブックが示す型に対し、Seeking SRE は型を現実の組織制約の中でどう曲げ運用するかの生々しい事例集として補完する。
理由: SRE は SLO を満たすために「システムの状態を正確に知る」ことを前提とするが、SRE 本自体は監視の哲学にとどまる。『オブザーバビリティ・エンジニアリング』は分散トレースや高カーディナリティイベントで未知の障害を探索する技術を補い、SRE が要求する観測能力を実装レベルで満たす。
理由: 『サイトリライアビリティワークブック』で SLO を運用に乗せると、SLI を正確に計測し違反の原因を追跡する基盤が要る。『オブザーバビリティ・エンジニアリング』はその計測・調査基盤を与え、SLO ベースの運用を支える観測のインフラを具体化する。
理由: Nygard『Release It!』でサーキットブレーカー等の安定性パターンを実装したら、それらが本番で実際に効いているかを観測する必要がある。『オブザーバビリティ・エンジニアリング』はパターンの発動状況やシステムの内部挙動を可視化し、「壊れない設計」が機能していることを検証可能にする。
理由: 『Release It!』の安定性パターンは個々のサービスを壊れにくくするが、システム全体の信頼性をどう目標化し組織で運用するかは別の問い。Google『SRE サイトリライアビリティエンジニアリング』はエラーバジェットや障害対応の体制で、個別の耐障害設計を組織的な信頼性管理へ統合する。
理由: Kubernetes で分散システムを運用すると、一部の障害が連鎖して全体を巻き込むカスケード障害に直面する。Nygard『Release It!』はサーキットブレーカーやバルクヘッドなど、障害を封じ込める安定性パターンを体系化し、K8s 運用に「壊れても止まらない」設計を持ち込む。
理由: K8s 上の多数のマイクロサービスを運用すると、従来の監視では「どこで何が起きたか」を追いきれなくなる。『オブザーバビリティ・エンジニアリング』は分散トレースや構造化イベントで分散システムの内部状態を可視化し、クラウドネイティブ運用に必須の観測能力を与える。
理由: 『チームトポロジー』で価値の速い流れを生む組織を設計したら、信頼性をどのチームがどう担うかという問いに行き着く。Google『SRE サイトリライアビリティエンジニアリング』はエラーバジェットや運用責任の分担といった、信頼性を組織文化として根付かせる具体策を示す。
理由: 『The DevOps ハンドブック』で DevOps の文化と実践を学んだら、それを超巨大組織が長期間どう運用しているかの実例へ。『Googleのソフトウェアエンジニアリング』は「時間の経過とともに変化するプログラミング」という視点で、大規模・長寿命なエンジニアリング文化の知見を与えるクロスドメインな橋渡し。
理由: 継続的デリバリーを実現するうえで、「どの環境でも同じように動く成果物」をどう作るかが鍵になる。Poulton『Docker Deep Dive』はコンテナによる環境の標準化・可搬性を基礎から解説し、CD パイプラインが運ぶアーティファクトの標準形をコンテナとして固める。
理由: 『Kubernetes Patterns』でアプリを K8s 上で正しく設計する型を学んだら、それを本番で運用し続ける現場知へ。『クラウドネイティブDevOps with Kubernetes』は設計パターンを実際の運用（監視・スケーリング・障害対応）へ接続し、設計と運用のギャップを埋める。
理由: 『入門 監視』で障害を検知する仕組みを整えたら、次は検知した障害をシステム側でどう受け流すかという設計へ。Nygard『Release It!』のサーキットブレーカーやタイムアウトといった安定性パターンは、監視で見えた障害を自動的に封じ込める実装の引き出しになる。
理由: Kubernetes を手続き的に kubectl で操作する段階を抜けたら、望ましい状態を Git で宣言し自動で収束させる GitOps へ。Yuen ら『GitOps and Kubernetes』は CNCF が定義する GitOps 原則（宣言的・バージョン管理・自動pull・継続的調整）を Argo CD 等で実装する方法を示す。
理由: 継続的デリバリーのパイプラインを構築できたら、その「あるべき状態」の管理を Git に一元化する GitOps へ進化させられる。『GitOps and Kubernetes』は CD の push 型デプロイを、Git をsingle source of truth とした pull 型・自動収束モデルへ発展させる道筋を示す。
理由: GitOps でデプロイの自動化・宣言化ができたら、それを含むクラウドネイティブ運用の全体像へ。『クラウドネイティブDevOps with Kubernetes』は GitOps を一要素として位置づけつつ、監視・セキュリティ・コストまで含めた K8s 運用の総合的なプラクティスを与える。
理由: Kubernetes の使い方を学ぶと、その上にどんな分散アプリを組み立てるべきかという設計の問いが立つ。Kubernetes の共同創設者 Brendan Burns『Designing Distributed Systems』は、複製ロードバランス・シャーディング・スキャッタギャザーなど再利用可能な分散パターンを K8s の語彙で提示する。
理由: Burns の本で分散システムの「構成パターン」を学んだら、その先にあるデータの一貫性・耐障害性という難所へ。Kleppmann『データ指向アプリケーションデザイン』はレプリケーション・分散トランザクション・合意形成を理論面から掘り下げ、分散パターンを支えるデータ層の原理を与える。
理由: SRE で信頼性を工学的に扱えるようになると、「セキュリティと信頼性は本来同じ設計課題ではないか」という問いに行き着く。Google『Building Secure and Reliable Systems』は SRE の延長線上で、セキュリティを後付けでなくシステム設計に組み込む原則を示し、信頼性とセキュリティを統合する。
理由: セキュアで信頼性の高いシステムを設計しても、その状態を継続的に観測できなければ侵害や劣化に気づけない。『オブザーバビリティ・エンジニアリング』は分散システムの内部を可視化する技術を与え、セキュア信頼性設計を「実際に守られているか検知できる」運用へ接続する。
理由: 『チームトポロジー』が提唱する「プラットフォームチーム」を実際にどう立ち上げ運営するかは、それ自体が一つの専門領域。Fournier & Nowland『Platform Engineering』は内部開発者プラットフォームの設計・組織・プロダクト戦略を扱い、チーム編成の理論を具体的なプラットフォーム構築へ接続する。
理由: 『Accelerate』が示す高パフォーマンス組織の能力を、開発者の認知負荷を下げる基盤として実装する道。Fournier & Nowland『Platform Engineering』はセルフサービス基盤によって開発チームの自律性と生産性を両立させる方法を説き、計測で見えた改善余地をプラットフォームへ落とし込む。
次に探索する
依存関係でつながる分野
Domain
バックエンド開発
API設計からサーバーサイドアーキテクチャ、認証・認可、非同期処理、 分散システム、パフォーマンス最適化まで、バックエンド開発の実装力と 設計原則を体系的に養うための学習パス。
Domain
データベース設計・運用
SQL基礎・リレーショナルモデル理論・正規化・物理設計・トランザクション・ NoSQL/分散DB・運用とスキーマ進化までを段階的に学び、論理空間（集合論・ 述語論理）と物理空間（ディスクI/O・並行性）を往復しながら、堅牢で スケーラブルなデータ基盤を設計・運用できる能力を獲得する学習パス。
Domain
ソフトウェア設計
クリーンコードからアーキテクチャ、テスト・品質文化まで、ソフトウェア設計の体系的学習パス。 コード品質、テスト駆動開発、ドメイン駆動設計、分散システム設計、DevOps/品質組織までカバー。