18-Month SRE and Platform Engineer Learning Roadmap

This roadmap covers the skills that matter most for SRE and platform work:

Each stage links to the free guides that go deeper on it. Where a paid guide from the bundle fits, I've noted it at the end of the stage.

If you're new to SRE, start with Cracking SRE. It's free, and it's the fastest way to see what the job looks like before you spend months on tools.

It covers:

Read it first, then use this roadmap as the order to learn everything else in.

SRE and platform engineering are about making software more reliable, safer to change, easier to operate, and easier for engineers to deploy and troubleshoot. Kubernetes, Terraform, and cloud dashboards are tools for that work.

The roles overlap, but they have different focuses:

In a small company, one person may do all three. Job postings often say SRE when the work is mostly DevOps, so ask the interviewer, "What does a typical week look like for someone in this role?"

Reliability is shared. When several teams can ship changes that affect users, no single team can fully own production. Google Cloud's reliability guidance describes reliability as a shared responsibility.

A platform is a set of integrated capabilities delivered through consistent self-service experiences, as the CNCF Platforms White Paper defines it. It isn't automatically a portal or a Kubernetes cluster. It might include repository templates, CI pipelines, deployment workflows, documented scripts, dashboards, access controls, and SOPs.

Start with the foundations that explain what software is doing:

By the end of this stage, you should be able to read a small service, write a health endpoint, query a database, automate a repetitive task, inspect a running process, and explain how an HTTP request reaches an application.

Free guides:

In the bundle: the Git and Bash and Python scripting guides go deeper on the shell and version-control skills in this stage.

Learn how software moves from source code to production:

A release isn't finished when CI turns green. It's finished when the new version serves traffic, health checks measure something meaningful, dashboards look normal, errors and latency are within acceptable limits, and someone knows how to roll back.

Don't deploy to 100% of production at once. Start with a small slice of traffic or one region, watch error rate and latency for 10 to 15 minutes, then widen the rollout. Tag images with the git commit SHA rather than latest, so you always know what is running.

Deployment controls matter most when several changes target the same environment. GitHub Actions documents protected environments, approvals, branch restrictions, secrets, and deployment concurrency in its continuous deployment and deployment controls guidance.

Free guide: Docker interview guide explains containers as restricted Linux processes, which makes most confusing behaviour predictable. It covers why docker stop sometimes takes exactly ten seconds, why an image can keep a secret you deleted, and why a one-line change can rebuild everything.

Choose one cloud provider and learn it well before studying several superficially. Focus on identity and access, virtual networks, subnets and routes, firewalls and security groups, load balancers, compute, storage, managed databases, queues, backups, monitoring, and basic cost controls.

Then use Terraform to build a small environment. Infrastructure as code makes configuration reviewable and versioned, but it won't make a weak design reliable on its own. Read the Terraform documentation, and follow these habits:

Kubernetes production guidance covers access control, resource limits, certificates, backups, and resilience. Don't copy a large production architecture into a beginner project without understanding its cost and operational risk.

Free guide: Database interview guide is the place to learn indexes, query plans, and locking. Start with a few million rows and EXPLAIN ANALYZE. It also covers why CREATE INDEX can block writes on a live table, and why one forgotten open transaction can hold back cleanup across the whole database.

Test your backups. Most teams test the backup process only after they need it, and an untested backup is not a backup. Know how backups are taken, how long a restore takes, and when the last restore was tested.

Observability helps you understand what is happening inside a system:

OpenTelemetry's observability primer explains how traces use spans to connect work across components. Each signal answers a different question. Metrics tell you latency rose at 3pm. Logs tell you which requests were slow. Traces tell you which service in the chain caused it. You need all three.

Start with signals tied to user experience and system capacity: request rate, error rate, latency, CPU and memory, disk utilisation, connection saturation, queue depth, database health, deployment version, and dependency failures.

Alert on conditions that need a human. Don't page someone for every CPU increase. Alert when users are already affected, a service objective is at risk, a resource is approaching a hard limit, or immediate action is required. Google's incident management guidance covers user-focused alerting and on-call preparation in more detail.

When an alert fires:

Timebox the investigation. If you haven't found a likely cause in about 15 minutes, escalate. Asking for help early is what senior engineers expect.

Start with one objective: 99.9% of valid API requests succeed over a rolling 30-day window.

Keep four terms separate:

Keep the SLO slightly tighter than the SLA. If you promise 99.9% externally, aim for 99.95% internally. That gap gives you room to fix problems before they become contractual violations.

For a 99.9% target over 30 days, the budget is about 43 minutes of downtime. For 99.99%, it's about 4 minutes a month. The gap between the two targets is a very different operational burden, covering redundancy, automated failover, and zero-downtime deployments.

When the error budget is healthy, the team can ship features and take riskier deployments. When it's nearly used up, the team pauses risky changes and focuses on reliability. That turns "reliability versus velocity" from a debate into a factual question. For example: "We have 4 minutes of budget left this month. That deployment has a 30% chance of causing 10 minutes of downtime. We're not shipping it this week."

Two recovery targets sit alongside these:

RTO is the target. Actual recovery time is the measurement. If your RTO is 30 minutes and your last three incidents took 45 minutes, you have a gap to close.

An incident starts when users are affected or about to be, not when an alert fires. During an incident, mitigate first and analyse later. Rolling back is often the quickest mitigation.

Narrate what you see, not what you guess. "Error rate is 40% on the payments service, started at 14:23, database connections are at 95% of the pool limit" is useful. "I think it's the database" isn't.

After the incident, write a blameless postmortem. Include a precise timeline, the root cause, and action items with an owner and a due date. "Improve monitoring" never gets done. "Add an alert for database connection pool utilisation above 80%, owned by a named engineer, due next Friday" does.

Build abstractions only after you understand the services beneath them. Otherwise you hide complexity instead of reducing it.

Start with one common service and build a small golden path. It should contain a repository template, a Dockerfile, CI checks, deployment configuration, secrets integration, a standard dashboard and alerts, ownership metadata, a runbook, and rollback instructions.

Treat the platform as an internal product. Measure whether it reduces support tickets, speeds up delivery, provides safer defaults, reduces repeated configuration errors, and makes troubleshooting easier.

Put these in the golden path so every team gets them by default:

Once the platform is running, security becomes part of the delivery path. Scan images in CI and in the registry, because an image that was clean when you built it may not be clean three months later. Rebuild on a schedule, not only when your code changes, and run containers as non-root with the smallest set of capabilities they need.

If you work near AI workloads, learn how GPU capacity, model serving, and data pipelines affect reliability in the same way that databases and queues do.

In the bundle: the DevSecOps guide and the AI infrastructure guide cover these topics.

A strong portfolio project shows the full operational lifecycle:

That shows more end-to-end ability than listing dozens of tools.

In interviews, the goal is to explain how a request moves through a system, deploy a change safely, detect when users are affected, investigate a failure with evidence, recover service under pressure, and choose an appropriate level of operational complexity. Saying "I don't know exactly, but here's how I'd find out" is a stronger answer than confidently stating something wrong.

In the bundle: the DevOps and SRE Resume Checklist covers the job-search side, so you can describe this project in terms of impact.

The roadmap points to guides in several places. If you want them in one place, the complete bundle includes the four free guides above and the paid guides mentioned in each stage.

Free: Cracking SRE, Linux, Networking, Database, and Docker interview guides.

Paid, in the bundle: Guided Learning map, Git, Bash and Python scripting, Kubernetes, Terraform, AWS, GCP, Azure, Linux performance, Nginx and load balancers, Redis and caching, Kafka and messaging, system design, DevSecOps, AI infrastructure, and the DevOps and SRE Resume Checklist.

Buying the bundle gives you one reference instead of buying each guide separately. Start with the guide that matches your next interview, then work through the rest as the role you're aiming for becomes clearer.

Get the complete bundle

👋 Find me on Twitter | Linkedin | Connect 1:1

Thank you for supporting this newsletter.
Y’all are the best.