If you've spent years keeping someone else's system alive and you're now trying to move into a DevOps title, the rejection you're hitting isn't about your skills. It's about what your résumé is shaped like.
You know which service degrades first when the queue backs up. You know which 3am alert means "go back to sleep" and which one means "get up now," and you've fixed things under pressure that the people who built them couldn't fix calmly at their desks. None of that shows up as a DevOps qualification, because it isn't written down as one — it's written down as a list of fires, and the job description in front of you is written as a list of pipelines.
That gets talked about as a skills gap. Mostly it isn't. It's a portfolio gap — and it closes faster than the career blogs make it sound (they love the "skills gap" framing, unsurprisingly; it's what sells the course).
The title change is smaller than it looks, and more specific than it looks
Production support and DevOps overlap enough that some companies just use the two names for the same job posting. Where they actually differ is direction of ownership: "DevOps engineers own the pipelines, infrastructure, and automation that get that code to production reliably and quickly," as one plain-language breakdown of the split puts it — the thing that produces the system, not the system itself once it exists. Educative's developer-vs-DevOps rundown draws the line right there.
You've been doing the second half's homework without getting credit for the first half's output. You diagnosed exactly why deploys kept failing on Fridays. Someone with a DevOps title on their badge would have gone and changed the deploy process so Fridays stopped mattering — the same instinct behind the progressive-rollout and blast-radius arguments I made a couple weeks back about routine changes, just aimed upstream at the process instead of downstream at the fire.
The gap is three tools deep, not a philosophy
Nearly 37% of IT leaders now name DevOps as their single largest technical hiring gap — not because the discipline is exotic, but because most candidates can talk about CI/CD in the abstract and can't point to a pipeline they actually own, according to a recent rundown of in-demand DevOps skills. The concrete list under that number is short: an infrastructure-as-code tool (Terraform is still the default), a CI/CD system you've owned end to end rather than "we used Jenkins," and enough Kubernetes to explain what actually happens between `kubectl apply` and a pod taking traffic.
None of that is a career change. It's roughly one system, rebuilt properly.
What you already have that the job posting never mentions
Here's the part nobody puts in the listing: the hardest thing to teach a DevOps hire is judgment under pressure, and you already have it. "Sysadmins who embrace automation and cloud become some of the most effective DevOps engineers," notes one 2026 roadmap for the transition, which also puts the realistic timeline at 6-12 months depending on cloud exposure. That tracks with what I've seen. It's shorter than people assume, because you're not learning a domain from zero — you're learning to describe a domain you already understand in code instead of memory.
Ever watched someone who's never carried a pager automate the wrong thing with total confidence? People who've kept production alive know which failure modes are worth automating around and which ones are one-offs, not worth the engineering cost. A DevOps hire with strong Terraform and no scar tissue doesn't have that filter yet. You do — the same way the agents I wrote about handling on-call toil are decent at the mechanics of a fix and bad at knowing which fix actually matters.
Close the gap with one system, not a certificate
Pick a system you already support — ideally one whose deploy process you've personally cursed at — and rebuild its path end to end: write the Terraform for its infrastructure, put its deploy under a real pipeline instead of a runbook, and if it touches Kubernetes, get its manifests under GitOps instead of hand-applied. Do the one system properly rather than three systems halfway; a single real artifact beats a shelf of finished courses. That's your portfolio, and it's the honest answer the next time someone asks "tell me about something you automated" — a much better question to walk in prepared for than "what's the difference between DevOps and SRE," which nobody agrees on anyway.
The reframe that actually gets you hired
Every incident story you're currently telling is shaped like "I found the problem and I fixed it." For a DevOps interview, tell the version that ends at "and I made it structurally impossible to happen the same way twice" instead — same incident, just a different last sentence. If your Friday-deploy story stops at "I rolled it back," that reads as production support. If it keeps going to "and then I changed the pipeline so a Friday deploy can't take the whole thing down," that reads as DevOps, and you can say it honestly, because you're going to go build it before anyone asks. It's the same shift I noticed on the interview side of this same market: panels increasingly care less about how fast you found the fire and more about what you did so it couldn't restart.
You're not starting a new career. You're finishing the sentence on the one you're already in.