I'll be honest: I'm confused, and I think a lot of beginners are too afraid to admit that in public. So let's just start here.
I'm a backend developer (Python, FastAPI, Docker, that world) trying to move toward DevOps and reliability work. I've read the definitions of SRE a dozen times — SLIs, SLOs, error budgets, toil, blameless postmortems — and I can repeat them back to you. But repeating definitions isn't the same as knowing what to actually do on a Monday morning if I wanted to start becoming an SRE.
Every roadmap I find online contradicts the last one. One says "learn Kubernetes first." Another says "no, learn Linux internals and networking first." Another says "just get good at coding and reliability will follow." I don't know who's right, and honestly, I don't know who's just repeating what they read somewhere else — the same way I might be doing right now.
So instead of guessing, I want to ask people who are actually doing this work.
What I actually need help with
Where do I genuinely start — not the idealized path, the real one? Do I need to be a strong backend/software engineer first, or can I start learning SRE-specific things in parallel? What did your actual starting point look like?
What tools/concepts are worth learning early vs. later? Monitoring (Prometheus/Grafana), incident response, Linux fundamentals, cloud platforms, Kubernetes, scripting — I can't learn all of it at once. What's the order that actually matters?
What mistakes do beginners make that waste their time? Am I at risk of over-investing in tools before understanding fundamentals? Or under-investing in fundamentals while chasing shiny tools? What should I actively avoid doing right now?
Are there beginner-unfriendly traps in this field? Things like: chasing certifications that don't actually matter, thinking you need production on-call experience before you can start learning, or assuming SRE is "DevOps with a fancier title" — anything like that I should watch out for?
How do you know you're actually making progress vs. just consuming content? This is my biggest confusion. I read, I watch talks, I nod along — but I don't know how to tell if any of it is sticking or turning into real skill.
Why I'm asking this way
I'd rather sound confused and get real answers than sound confident and learn the wrong things for six months. If you started as a beginner and figured this out — or if you're mentoring someone who did — I want to hear the messy, honest version, not the polished roadmap version.
What would you tell confused-beginner-me if I messaged you right now asking "how do I actually start"?
Top comments (2)
Asking this in public takes more than most of the roadmap posts do, so here is the messy version you asked for. The shift that actually moved me from "consuming content" to "making progress" was owning something small enough that a bad change woke me up. Reading about error budgets teaches the vocabulary; deciding to page on a threshold you picked yourself teaches the trade-off, because within a week you are explaining your own false positives to someone.
The trap I would name for your list: building the dashboards before you have an opinion about what should hurt. Prometheus and Grafana are easy to install and useless as a first step — the skill is writing the alert, then living with it. And the question you asked about progress has a cheap test: can you take one user-facing journey, define what "working" means for it, and defend that definition when it is wrong at 3am? If yes, you are doing the job, not studying it.
The "own something small enough that a bad change wakes you up" line is going to stick with me. I think I've been treating SRE as something to understand before I do, and you're basically saying that's backwards — the understanding comes from the consequence, not before it.
Quick follow-up, if you don't mind: when you picked that first threshold to page on, how did you decide where to draw the line? Did you start too sensitive and dial it back, or too loose and tighten it up? I'm guessing "get it wrong first" is part of the answer, but I'd rather hear how you actually approached that first guess than assume.