Keep your DevOps base and add what SRE is really judged on: SLOs and error budgets, alerting on burn rate, running incidents and writing postmortems, and debugging production calmly. Prove it with one service you operate end to end, then move internally or apply with that evidence.
What people tell me
I have been working in DevOps for a couple of years. I write pipelines, manage Terraform and deploy to Kubernetes, and I am the person people call when something breaks. I keep seeing site reliability engineer roles and they look like the natural next step, but I cannot tell what I am missing. Is SRE just DevOps with a different title, or do I need to learn something new? I do not want to spend a year on certifications that do not help.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- SRE is less about new tools and more about running services against numbers: SLIs, SLOs and error budgets.
- The skills that separate SRE from DevOps are burn-rate alerting, incident command, postmortems and fast production debugging.
- Operate one service end to end with an SLO, alerts, a runbook and a postmortem; that is stronger evidence than a certificate.
- Moving internally is often the easiest route: volunteer for on-call, incident reviews and SLO work where you already are.
- Expect on-call in the role, and ask how it is run before you accept an offer.
Is SRE just DevOps with a new title?
Not quite, and the difference is good news for you. DevOps is mostly about how software gets built and shipped: pipelines, infrastructure as code, containers. Site reliability engineering is about how a service behaves once it is running, measured in numbers users would recognise. You already have most of the tools. What you are missing is usually a way of working.
In practice, an SRE is judged on questions like these:
- What reliability does this service promise, and how much failure is it allowed this month?
- Does the pager go off only when users are actually hurt?
- When something breaks, how quickly is it mitigated, and does the postmortem lead to a real fix?
- Is the team spending its time on engineering, or drowning in repetitive manual work?
What to learn, in order
I would work through these in this order, because each one builds on the last:
- SLIs, SLOs and error budgets. Learn to write an SLI as good events over valid events, set a target, and convert it into minutes of allowed downtime. The nines table should become second nature.
- Observability beyond a first dashboard. PromQL you can write without searching, histograms and percentiles, cardinality, and OpenTelemetry traces you can follow from a graph to a log line.
- Incidents and postmortems. Burn-rate alerts, incident roles, mitigating before diagnosing, and blameless postmortems with owned action items.
- Kubernetes in production. Troubleshooting flow, disruption budgets, zone spreading, graceful shutdown and upgrades.
- Capacity, chaos and on-call. Simple capacity maths, a few chaos experiments, and an on-call rotation that people can sustain.
The Platform engineering and SRE roadmap follows exactly this path, starting where the DevOps and cloud roadmap ends, and the cheat sheet has the SLO maths, PromQL, incident roles and a postmortem template on one page.
What to read
The two Google books are free online and still the best starting point: the Site Reliability Engineering book for the ideas, and The Site Reliability Workbook for how to actually implement SLOs and alerts. For hands-on debugging practice, SadServers gives you broken servers and a timer, which is closer to a real page than any course.
Prove it with one service
Hiring managers for SRE roles want to hear how you ran something, not which courses you finished. Pick one service, even a side project, and run it properly:
- Two SLIs and an SLO, with the error budget written down.
- A dashboard, burn-rate alerts and a runbook for each alert.
- One chaos experiment, such as killing a pod or adding latency, with a written result.
- A practice incident and a blameless postmortem.
A project like a status page with multi-region uptime checks covers most of this and is easy to explain in an interview.
The easiest route is often internal
If your company has an SRE or platform team, ask to join their on-call shadowing, sit in on incident reviews, or offer to write SLOs for a service your team owns. Internal moves skip the hardest part of switching roles, which is convincing strangers you can do it. If there is no SRE team, introducing SLOs and postmortems where you are is itself SRE work you can talk about later.
One honest warning
SRE roles almost always include on-call. That is where you learn fastest, but it can burn people out when it is badly run. Before accepting an offer, ask how often the rotation is paged and what happens after a bad night.
If you want a second opinion on your plan, create a free account to follow the roadmap and track your progress, or book a session and we can go through where you are and what to do next.
Was this answer helpful?
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open: sign up and your account is active shortly after. Prefer to talk? A free call works too.