Part 21 -- Where to go next

You have covered, in depth, what an operating system does, how Linux exposes that to you at the command line, and how containers and Kubernetes package and run software at scale. You also covered the advanced operational layer: fleet drift, systemd, storage, networking, observability, hardening, and incident response. This last part is deliberately short: an honest accounting of what still sits beyond this guide, and how to keep learning once you close it.

Chapter 83 -- Honest gaps and a study plan

In one sentence

This guide gave you a strong practical foundation across OS concepts, Linux, containers, Kubernetes, and production operations. That is still not "all of Linux." Naming the remaining specialist depths precisely is more useful than pretending any single guide can be complete.

Why this matters

Knowing what you don't know is a professional skill in itself. A beginner SRE who says "I understand the fundamentals of process scheduling and containers, and I know that I have not yet gone deep on distributed consensus or kernel networking internals" is more hireable and more trustworthy than one who either overclaims mastery or has no sense of the shape of the field at all. This chapter is a map of the edges.

How it actually works

Honest gaps, organized by phase, with a concrete next resource for each:

   PHASE 1 (OS concepts) -- what this guide under-covered:

     - Kernel internals beyond the syscall boundary (how the scheduler,
       memory manager, and VFS are actually implemented in C).
       Next: "Linux Kernel Development" by Robert Love; read the
       actual kernel source for a subsystem you care about.

     - Filesystem internals in depth (how ext4's journal actually
       works, B-trees in Btrfs/XFS, copy-on-write).
       Next: "Operating Systems: Three Easy Pieces" (free online,
       ostep.org) -- covers this more rigorously than this guide did.

     - Real-time operating systems and embedded constraints.
       Not covered here at all -- a genuinely different field with
       different tradeoffs (predictability over throughput).

   PHASE 2 (Linux fundamentals) -- what this guide under-covered:

     - Advanced networking beyond host-level diagnosis: BGP, EVPN/VXLAN,
       traffic engineering, load-balancer internals, and routing at scale.
       Ch 69 gave you the Linux packet-path model; running a network team is
       a deeper specialization.
       Next: "TCP/IP Illustrated" by W. Richard Stevens; the
       Linux Advanced Routing & Traffic Control HOWTO (lartc.org).

     - Security hardening at dedicated security-engineering depth:
       SELinux/AppArmor policy authoring, kernel exploit mitigation research,
       audit frameworks, incident forensics, and compliance operations. Ch 71
       gave you the Linux operator's model; security is its own field.
       Next: the [[real-life-security-guide-v1]] companion guide in
       this wiki's security/ folder covers this ground in depth.

     - Distributed systems fundamentals (consensus, CAP theorem,
       replication) -- necessary for understanding *why* etcd and
       Kubernetes's control plane are built the way they are, only
       gestured at in Chapter 54.
       Next: "Designing Data-Intensive Applications" by Martin
       Kleppmann.

   PHASE 3 (Containers/Kubernetes) -- what this guide under-covered:

     - Kubernetes networking internals (CNI plugins, how Services
       actually route packets via iptables/IPVS, service meshes like
       Istio/Linkerd).
       Next: "Kubernetes Networking" chapters in "Kubernetes in
       Action" by Marko Luksa; the CNCF's Istio documentation.

     - Multi-cluster and multi-region operation, GitOps (ArgoCD/Flux),
       and progressive delivery (canary releases, feature flags at
       the infrastructure layer).
       Next: CNCF's own "Cloud Native Landscape" as a map of what
       exists; ArgoCD's official documentation as a hands-on start.

     - Observability platform engineering: Prometheus architecture and PromQL
       at scale, distributed tracing storage, high-cardinality control, log
       pipeline economics, and profiling as a service. Ch 70 gave you the
       troubleshooting ladder; operating the observability platform is a
       specialty.
       Next: "Distributed Systems Observability" by Cindy Sridharan
       (free online).

     - Cost and capacity planning at scale -- right-sizing a fleet of
       nodes, spot/preemptible instance strategy, multi-tenant
       cluster isolation.
       Next: your cloud provider's own well-architected / cost
       optimization documentation (AWS, GCP, and Azure each publish
       one).

A study plan, if you want one rather than just a map: pick ONE gap above that's closest to your actual job's needs, go deep on it for a month using the named resource, and come back to this guide's capstones (Part 18) using what you learned as an added constraint (e.g. "redo Project 3, but also add a NetworkPolicy" once you've studied Kubernetes networking). Breadth-first learning (a little of everything) is how you got here; depth-first learning (one thing at a time, thoroughly) is how you become genuinely senior at any one of them.

Real-world example

This gaps-and-resources structure mirrors how most senior engineers actually describe their own learning path when asked in interviews or mentoring conversations: nobody claims to have learned "all of Linux" or "all of Kubernetes" from one source. The common pattern, visible across countless engineering blogs and conference "how I learned X" talks, is a broad foundational resource (often a book or course much like this guide) followed by picking up genuine depth in two or three specific areas that turned out to matter for their actual job -- one engineer goes deep on container networking because their company runs a service mesh, another goes deep on filesystem internals because they work on a database engine. The map above is deliberately structured the same way: broad coverage here, named depth resources for whichever direction your actual work pulls you.

Try it yourself

Pick one gap from the list above that's closest to something your current or target job actually touches. Spend 30 minutes right now finding and bookmarking the named resource (or an equivalent you prefer), and write one sentence about why that gap matters for your specific situation. That sentence is worth more than the bookmark -- it's what will make you actually go back and use it.

Common mistakes

Trying to close every gap listed here before considering yourself "ready" -- this guide's whole premise is that breadth-first, practical competence is valuable on its own; depth can be added incrementally, driven by actual need.
Choosing a depth topic based on what sounds impressive rather than what your actual job or target job needs.
Reading about a gap area without doing the equivalent of this guide's "Try it yourself" sections for it -- reading "TCP/IP Illustrated" without ever running tcpdump on your own traffic teaches you far less than reading half of it and testing every claim.

Across the series

Several of the gaps above are covered by the companion guides in this wiki:

Networking beyond Part 11: Networking from Zero (TCP/IP) goes from Ethernet frames to BGP, with packet-capture practice, and its Part 13 covers host networking internals, firewalls, tunnels, and Kubernetes networking at professional depth.
What your servers serve: The HTTPS Request Lifecycle covers TLS, HTTP, proxies, CDNs, and SLOs, with a Go production HTTPS server.
One request, layer by layer: The OSI guide, a short read that ties the stack together and works well for teaching others.
Writing the software: the Go guide and its 120-day plan, whose later weeks build production network services that need exactly the Linux knowledge in this guide.
Attacking and defending these systems: Security from Zero (SSH hardening, OpenSSL, a CA of your own) and Security Engineering in Depth: container isolation and escapes (Chapter 15), Kubernetes RBAC, admission, and runtime security (Chapters 17–20), and secrets (Chapter 73).

Check yourself

Name one gap from the list above that is directly relevant to your own current job or the job you want next, and explain why in one sentence.
Why might "go deep on one gap for a month" be more valuable at this stage than "read a little about every gap"?
This guide mentioned but did not teach service meshes (Istio/Linkerd). Based on what you learned about Kubernetes Services in Chapter 56, what problem do you think a service mesh exists to solve that a plain Service does not?