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
18 books
Docker Deep Dive
Nigel Poulton
Practical Monitoring
Mike Julian
Cloud Native DevOps with Kubernetes
John Arundel, Justin Domingus
Designing Distributed Systems
Patterns and Paradigms for Scalable, Reliable Services
Brendan Burns
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
Marko Lukša
Platform Engineering
A Guide for Technical, Product, and People Leaders
Camille Fournier, Ian Nowland
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
Kubernetes Patterns
Reusable Elements for Designing Cloud Native Applications (2nd ed.)
Bilgin Ibryam, Roland Huß
LLMOps
Abi Aryan
Observability Engineering
Charity Majors, Liz Fong-Jones, George Miranda
Effective Platform Engineering
Ajay Chankramath, Nic Cheneweth, Bryan Oliver, Sean Alvarez
Release It!, 2nd Edition
Design and Deploy Production-Ready Software
Michael T. Nygard
Seeking SRE
Conversations About Running Production Systems at Scale
David N. Blank-Edelman
Site Reliability Engineering
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy
The Site Reliability Workbook
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, Stephen Thorne
Dependencies
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: 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: 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 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: 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.
- 22Designing Distributed SystemsDesigning Data-Intensive ApplicationsRecommended / 分散パターンから分散データシステムへ
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: Where Fournier & Nowland's 'Platform Engineering' discusses launching and running a platform team from a leadership perspective, 'Practical Platform Engineering' digs deeper into implementation—governance, control planes, and success metrics. After grasping the strategy, this moves you into concrete design and build steps.
Sources
Reason: After building a foundation in Pods, Deployments, and the extension API with 'Kubernetes in Action', move to the practical question of building an internal developer platform (IDP) on top of it. 'Practical Platform Engineering' covers control planes and service extensions, applying K8s knowledge to designing a self-service foundation.
Sources
Reason: Where 'Observability Engineering' teaches observability for distributed systems in general via structured events and distributed tracing, 'LLMOps' applies that thinking to running LLM-based applications, connecting it to LLM-specific observation challenges like evaluation-metric design and early detection of hallucination.
Sources
Reason: Where Google's 'Site Reliability Engineering' frames engineering reliability for general services via SLIs/SLOs and error budgets, 'LLMOps' applies that operating philosophy to the new target of LLM applications, organizing the production concerns—including governance and cost management—specific to running them.
Sources
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.