Domain
DevOps / SRE
A staged learning path covering DevOps culture, continuous delivery, SRE, observability, containers, and IaC — moving from narrative to implementation. Build modern operations that balance high reliability and agility across organization, process, and technology.
The Terrain of This Field
The terrain of DevOps / SRE can be read as a continent you begin climbing from the gentle "plateau of culture and measurement," cross a technical main ridge, and arrive at the open field of operations. The opening plateau is the foundation of "why and how to measure," before technology itself: you gain a sense of the problem through narrative, take up a map of practice, and rise along the ridgeline of continuous delivery.
Beyond the plateau runs the mountain range of "containers and orchestration" — the highest technical main ridge. From the base camp of containers you climb to the summit of Kubernetes, and from there the ridgeline branches into patterns, distributed design, IaC, and GitOps: the craft of moving mountains declaratively.
Past the mountains spreads the field of "reliability and observability." With the operating philosophy of SRE at its core, the terrain continues through resilience design, integration with security, and from monitoring toward observability. The key to surveying this field is climbing "speed" and "robustness" together, shuttling across the three axes of organization, process, and technology.
Follow the arrows to read in order / solid = required, dashed = recommended
Share this map
Grouping
Difficulty
Difficulty
Dependencies
Computing layout...
Books in this domain
22 books
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
Dependencies
Reason: 'The Phoenix Project' lets you experience the chaos of IT operations through a novel, internalizing why DevOps is needed. Once you feel the problem, the royal road is to learn the solutions as systematic practices in 'The DevOps Handbook' by the same author team (Gene Kim et al).
Reason: Where 'The Phoenix Project' is told from the operations side, its companion 'The Unicorn Project' retells the same events from a developer's perspective. For readers who enjoyed the novel, it is a sister volume to explore another angle—developer productivity and technical excellence—while staying entertained.
Reason: After grasping the developer-side frustrations in 'The Unicorn Project', the next stage is translating them into concrete practices. 'The DevOps Handbook' covers techniques from deployment automation to feedback loops, turning the problem awareness from the novel into implementable procedures.
Reason: Where 'The DevOps Handbook' surveys broad DevOps practices, Humble & Farley's 'Continuous Delivery' digs into its core—building deployment pipelines—as the original source. Ideal for solidifying the theoretical backbone of CI/CD after grasping the overall picture of practice.
Reason: Once you adopt practices, you want to measure whether they actually work. 'Accelerate' provides the scientific basis—grounded in DORA research—to quantify organizational performance via four metrics: deployment frequency, lead time, change failure rate, and time to restore.
Reason: After you can build deployment pipelines from 'Continuous Delivery', you need a yardstick to measure the results. 'Accelerate' shows statistically that CD capabilities predict organizational performance, giving you the rationale to connect technical investment to business metrics.
Reason: Even if you adopt DevOps as a technical practice, fast flow won't emerge while the org structure stays siloed. Skelton & Pais's 'Team Topologies' presents organizational design that turns Conway's Law to your advantage via four team types and interaction modes, aligning the two wheels of technology and organization.
Reason: The evidence in 'Accelerate'—that loosely coupled architecture and autonomous teams drive high performance—naturally calls for a concrete theory of organizational design. 'Team Topologies' offers the organizational patterns to implement that evidence, serving as a data-driven guide for structuring teams.
Reason: To run a continuous delivery pipeline reliably, not just the app but also the infrastructure must be reproducible. Kief Morris's 'Infrastructure as Code' systematizes the principles of defining servers and networks as code—version-controlled, tested, and applied automatically—securing the environmental consistency that CD presupposes.
Reason: Once you understand the principles of IaC, move to a concrete tool that realizes them. Brikman's 'Terraform: Up & Running' walks hands-on through Terraform, which declaratively defines cloud resources, turning abstract IaC principles into configuration code that actually runs.
Reason: After understanding how to build and run a single container in Poulton's 'Docker Deep Dive', the challenge in production becomes orchestrating many containers together. Lukša's 'Kubernetes in Action' explains container orchestration from the ground up, scaling you from one container to distributed operation.
Reason: After mastering basic Kubernetes usage, the next stage is learning established solutions to recurring design problems on top of it. Ibryam & Huß's 'Kubernetes Patterns' provides a pattern language—sidecars, health checks, and more—for correctly designing cloud-native applications on K8s.
Reason: After understanding how K8s works in 'Kubernetes in Action', move to the practical question of operating it in production. Arundel & Domingus's 'Cloud Native DevOps with Kubernetes' systematizes field wisdom for running K8s—deployment, monitoring, security, and cost management.
Reason: A branch for those who want to realize continuous delivery principles in a K8s environment. 'Cloud Native DevOps with Kubernetes' covers deployment strategies and pipeline construction on K8s, concretizing general CD knowledge into Kubernetes-native operational patterns.
Reason: Once you can provision cluster infrastructure with Terraform, advance to operating the workloads running on top of it. 'Cloud Native DevOps with Kubernetes' supplies the operational-layer knowledge for actually running a K8s cluster you prepared with IaC, making the path from provisioning to operation continuous.
Reason: After designing 'watch predefined metrics' monitoring with Julian's 'Practical Monitoring', advance to observability, which lets you explore even unknown failures. Majors et al.'s 'Observability Engineering' explains systems where high-cardinality events let you ask 'why did it happen?' after the fact, going beyond the limits of monitoring.
Reason: Where 'The DevOps Handbook' preaches collaboration between development and operations, Google's 'Site Reliability Engineering' shows the concrete form of solving the operations side 'with software engineering'. With error budgets and SLOs to engineer reliability, it is a natural evolution of DevOps.
Reason: After designing 'what to measure' with 'Practical Monitoring', advance to the philosophy of tying those metrics to organizational decisions. Google's 'Site Reliability Engineering' elevates monitoring data—via SLIs/SLOs/error budgets—into criteria for 'when to halt feature work and invest in reliability'.
Reason: Where 'Site Reliability Engineering' articulates principles distilled from Google's practice, its sequel 'The Site Reliability Workbook' shows 'how to implement it at your own company' with concrete procedures and case studies. Theory first, then the implementation volume—a required progression.
Reason: After learning Google-originated SRE theory, you want to know how others adapt and practice it. Edited by Blank-Edelman, 'Seeking SRE' is a collection of contributions from many practitioners, offering diverse applications of SRE in non-Google contexts and broadening the scope of the principles.
Sources
Reason: After grasping SRE implementation procedures in 'The Site Reliability Workbook', gather more varied field voices in 'Seeking SRE'. Against the templates the workbook presents, 'Seeking SRE' complements them as a vivid case collection of how those templates get bent and operated within real organizational constraints.
Sources
Reason: SRE presupposes 'knowing the exact state of the system' to meet SLOs, but the SRE book itself stays at the philosophy of monitoring. 'Observability Engineering' supplements the techniques—distributed tracing, high-cardinality events—to explore unknown failures, satisfying at the implementation level the observation capability SRE demands.
Reason: Once you put SLOs into operation with 'The Site Reliability Workbook', you need a foundation to measure SLIs accurately and trace the causes of violations. 'Observability Engineering' provides that measurement-and-investigation foundation, concretizing the observation infrastructure that supports SLO-based operations.
Reason: After implementing stability patterns like circuit breakers from Nygard's 'Release It!', you must observe whether they actually work in production. 'Observability Engineering' makes the activation of those patterns and the system's internal behavior visible, making it verifiable that the 'unbreakable design' is functioning.
Reason: The stability patterns in 'Release It!' make individual services harder to break, but how to set targets for whole-system reliability and operate it organizationally is a separate question. Google's 'Site Reliability Engineering' integrates individual fault-tolerant design into organizational reliability management through error budgets and incident-response structures.
Reason: Operating distributed systems on Kubernetes, you face cascading failures where one fault drags down the whole. Nygard's 'Release It!' systematizes stability patterns—circuit breakers, bulkheads—that contain failures, bringing 'keep running even when it breaks' design into K8s operation.
Reason: Operating many microservices on K8s, traditional monitoring can no longer trace 'where and what happened'. 'Observability Engineering' makes the internal state of distributed systems visible via distributed tracing and structured events, providing the observation capability essential to cloud-native operation.
Reason: After designing an organization for fast flow of value with 'Team Topologies', you arrive at the question of which team owns reliability and how. Google's 'Site Reliability Engineering' presents concrete practices—error budgets, sharing of operational responsibility—for embedding reliability as organizational culture.
Reason: After learning DevOps culture and practices in 'The DevOps Handbook', move to a concrete example of how a hyperscale organization operates them over the long term. 'Software Engineering at Google' frames engineering as 'programming integrated over time', offering insight into large-scale, long-lived engineering culture as a cross-domain bridge.
Reason: A key to achieving continuous delivery is producing an artifact that 'runs the same everywhere'. Poulton's 'Docker Deep Dive' explains container-based standardization and portability from the ground up, fixing the standard form of the artifact a CD pipeline ships as a container.
Reason: After learning the patterns for correctly designing apps on K8s in 'Kubernetes Patterns', move to the field knowledge of keeping them running in production. 'Cloud Native DevOps with Kubernetes' connects design patterns to actual operations—monitoring, scaling, incident response—closing the gap between design and operation.
Reason: After setting up failure detection with 'Practical Monitoring', advance to designing how the system itself absorbs the detected failures. The stability patterns in Nygard's 'Release It!'—circuit breakers, timeouts—become an implementation toolkit for automatically containing the failures monitoring surfaces.
Reason: Once you move past operating Kubernetes imperatively with kubectl, advance to GitOps, where you declare the desired state in Git and let it converge automatically. Yuen et al.'s 'GitOps and Kubernetes' shows how to implement the GitOps principles defined by CNCF—declarative, versioned, pulled automatically, continuously reconciled—with tools like Argo CD.
Reason: After building a continuous delivery pipeline, you can evolve it into GitOps, centralizing management of the 'desired state' in Git. 'GitOps and Kubernetes' shows how to develop CD's push-style deployment into a pull-style, auto-converging model with Git as the single source of truth.
Reason: Once GitOps automates and declaratively manages deployment, step back to the whole picture of cloud-native operation that includes it. 'Cloud Native DevOps with Kubernetes' positions GitOps as one element while providing comprehensive K8s operational practices spanning monitoring, security, and cost.
Reason: Learning to use Kubernetes raises the design question of what distributed apps to build on top of it. By Kubernetes co-founder Brendan Burns, 'Designing Distributed Systems' presents reusable distributed patterns—replicated load-balanced services, sharding, scatter/gather—in the vocabulary of K8s.
Reason: After learning structural 'patterns' of distributed systems from Burns's book, advance to the hard part beyond them—data consistency and fault tolerance. Kleppmann's 'Designing Data-Intensive Applications' digs theoretically into replication, distributed transactions, and consensus, providing the data-layer principles that underpin distributed patterns.
Reason: Once SRE lets you handle reliability as engineering, you arrive at the question 'aren't security and reliability fundamentally the same design problem?'. Google's 'Building Secure and Reliable Systems' extends SRE to show principles for building security into system design rather than bolting it on, integrating reliability and security.
Reason: Even if you design a secure and reliable system, you cannot notice breaches or degradation without continuously observing its state. 'Observability Engineering' provides the techniques to make the internals of distributed systems visible, connecting secure-and-reliable design to operation where 'whether it is actually upheld' can be detected.
Reason: How to actually launch and run the 'platform team' that 'Team Topologies' advocates is its own discipline. Fournier & Nowland's 'Platform Engineering' covers the design, organization, and product strategy of internal developer platforms, connecting team-structure theory to concrete platform building.
Reason: A path to implementing the high-performing organizational capabilities shown in 'Accelerate' as a foundation that lowers developers' cognitive load. Fournier & Nowland's 'Platform Engineering' explains how self-service platforms reconcile team autonomy with productivity, turning the improvement opportunities revealed by measurement into a platform.
Explore next
Connected fields
Domain
Backend Development
A learning path to systematically build implementation skill and design principles for backend development — from API design and server-side architecture to authentication, async processing, distributed systems, and performance optimization.
Domain
Database Design & Operations
A learning path that builds the ability to design and operate robust, scalable data foundations — covering SQL fundamentals, relational model theory, normalization, physical design, transactions, NoSQL/distributed databases, and operational schema evolution. Travel between logical (set theory, predicate logic) and physical (disk I/O, concurrency) spaces along the way.
Domain
Software Design
A systematic learning path for software design — from clean code to architecture, testing, and quality culture. Covers code quality, TDD, DDD, distributed system design, and DevOps/quality organization.