The Site Reliability Engineering Roadmap

Everything an SRE touches eventually runs on a Linux host and talks over a network. Learn processes and signals, memory and the OOM killer, file systems and inodes, systemd, permissions, and the core debugging tools. For networking, learn IP addressing and subnets, routing basics, TCP behaviour including handshakes and retransmission, DNS resolution and caching, TLS, HTTP, and load balancing.

The test of this stage is diagnosis: given a slow or broken host, can you find out why without guessing?

SRE exists to replace repetitive operational work with software. Learn one language well. Go is common in infrastructure tooling; Python is common for automation and glue. Write tools that are safe to run twice, handle partial failure, and log what they did. Add shell scripting for small tasks, and learn where shell stops being the right tool.

Learn one major cloud provider's core services: compute, networking, identity and access, storage, and managed databases. Learn containers properly, including images, networking, and resource limits. Learn Kubernetes to the point where you can deploy, debug a crashlooping pod, and explain scheduling and service discovery. Manage all of it with infrastructure as code, and learn why drift between code and reality causes incidents.

Metrics, logs, and traces, and when each answers a question. Learn to instrument a service, build dashboards that show user impact rather than host statistics, and write alerts that are actionable. A good exercise is to take a service you built, define what healthy means for its users, and alert only on that.

Learn incident roles, severity levels, communication, and mitigation patterns such as rollback, failover, and load shedding. Learn to write blameless postmortems with contributing causes and owned actions. Then learn SLIs, SLOs, and error budgets, and practise the conversation where an exhausted budget slows feature work. This is the stage where operations becomes engineering.

Retries, timeouts, backpressure, idempotency, consensus, replication, and cascading failure. Read public postmortems from large providers: they are free case studies in how real systems fail. Capacity planning and performance analysis also belong here.

• Collecting tools instead of depth. Knowing the names of twenty observability products matters less than being able to explain why a latency percentile moved.
• Skipping networking. A large share of hard incidents involve DNS, TLS, load balancers, or connection behaviour. Engineers who avoid networking get stuck on exactly those.
• Learning Kubernetes before Linux. Most container problems are Linux problems wearing a different interface: resource limits, signals, file systems, and networking namespaces.
• Treating certifications as the goal. They can help with screening, but interviews test whether you can debug, not whether you passed an exam.
• Never being on call. Reading about incidents is not the same as handling one. Volunteer for a rotation, shadow one, or run your own service long enough to be woken by it.

New SREs usually start by joining an on-call rotation as a secondary, fixing noisy alerts, improving runbooks, and automating one painful manual task. That is not busywork. Each of those teaches how the production system actually behaves and where its weak points are.

By the end of the first year, a strong SRE owns the reliability of at least one service: its SLOs, its alerts, its capacity, and its postmortem actions. The habit that matters most is writing things down, because the next engineer on call depends on it.

Some companies hire associate or graduate SREs directly, and they test fundamentals: Linux, networking, a language, and problem solving. More often, engineers move into SRE from system administration, support engineering, network engineering, or backend development, bringing either operations depth or coding depth and building the other.

A homelab or a small cloud project you run continuously, with monitoring, alerts, deliberate failure testing, and written postmortems of what broke, is strong evidence for either route.