"How do I get into DevOps?" is a question I get often enough from junior support and sysadmin folks that it's worth writing down properly, instead of re-explaining it in a different order every time. The honest answer is that DevOps isn't a single skill or a certification — it's a set of overlapping competencies (systems, automation, delivery pipelines, observability) that you build in roughly the order your job actually needs them, not the order a course outline presents them. Here's the roadmap I'd actually give someone starting from a hosting/sysadmin background in 2026, not a generic list copied from a bootcamp brochure.
Start from where you already are
If you're coming from web hosting, sysadmin, or support work — like most of the people who ask me this — you already have a real head start that people coming from pure development don't: you've likely already dealt with Linux servers, DNS, SSL, backups, and the "why is this down" 2am reality of production systems. That's not a detour from DevOps; it's half of it. The gap is usually on the automation and delivery side, not the systems side. Keep that in mind so you don't waste time re-learning things you already know from a different angle.
Stage 1 — Solid Linux and networking fundamentals
Everything else sits on top of this. If you can't comfortably work through a service that won't start, read a firewall rule, or explain what a load balancer actually does to traffic, the tools built on top of these fundamentals (Docker, Kubernetes, CI/CD) will feel like magic instead of engineering — and magic is what breaks first under pressure. Concretely: process management (systemd), filesystem and permissions, package management, basic networking (DNS, TCP/IP, routing, firewalls), and comfort with the shell for real troubleshooting, not just copy-pasted one-liners.
Stage 2 — Version control and scripting, properly
Git beyond add, commit, push — branching strategies, rebasing, resolving conflicts without panic, and understanding what a pull request review is actually for. Alongside that, enough scripting (Bash for glue and quick fixes, Python for anything with real logic) to automate a repetitive task end-to-end, not just paste commands from a wiki page. This stage is where "DevOps" starts, in the literal sense: automating what used to be manual.
Stage 3 — Containers
Docker first, deeply — building images properly (layer caching, multi-stage builds, not running as root inside the container, keeping images small), not just docker run from a tutorial. Understand what a container actually is (namespaces and cgroups, not "a lightweight VM" — that mental model breaks down the first time you debug a networking issue between containers). Once Docker is genuinely comfortable, not just "I got a container running once," move to orchestration.
Stage 4 — Orchestration (Kubernetes, realistically)
This is the stage most roadmaps rush, and it's the stage most people struggle with, so pace it deliberately. Kubernetes' core objects (Pods, Deployments, Services, Ingress, ConfigMaps/Secrets) and the reconciliation-loop mental model (you declare desired state, the control plane works to make it real, continuously) is the conceptual leap. Don't skip straight to a managed service without understanding what it's managing for you — debugging a broken deployment on EKS/GKE is much harder if you've never seen what the control plane is actually doing underneath. I go deeper on the Docker-vs-Kubernetes decision itself in Docker vs Kubernetes: Choosing the Right Tool, Not the Trendy One.
Stage 5 — CI/CD
Build, test, and deploy pipelines — this is where "automation" becomes "delivery." Start with a single, boring pipeline (lint → test → build → deploy to staging) before reaching for anything elaborate. The skill that actually matters here isn't knowing every feature of GitHub Actions or GitLab CI — it's understanding pipeline design: what should block a merge, what should run in parallel, where secrets live safely, and how a rollback actually works when (not if) a deploy goes wrong. Full walkthrough in CI/CD From Beginner to Production: A Practical Pipeline Guide.
Stage 6 — Infrastructure as Code
Once you're comfortable deploying application code through a pipeline, apply the same discipline to infrastructure itself: Terraform (or your cloud's native IaC tool) instead of hand-clicking through a console. The value isn't just "it's faster" — it's that infrastructure changes become reviewable, versioned, and repeatable, the same way code changes are. This is also where you start thinking in terms of environments (dev/staging/prod) as genuinely reproducible, not "prod is the one nobody's allowed to touch by hand, except everyone does anyway."
Stage 7 — Observability
Logs, metrics, and traces — in that rough order of how most teams actually adopt them. Centralized logging first (so you're not SSHing into six servers to find one error), then metrics and alerting (so you know something's wrong before a customer tells you), then distributed tracing once your architecture is complex enough that a single request touches multiple services and you need to see the whole path. The discipline that matters more than any specific tool: alert on symptoms that affect users, not on every internal metric that moves — alert fatigue is a real, measurable productivity killer on ops teams.
Stage 8 — Security as a continuous practice, not a checklist
Secrets management (never in code, never in a CI log), dependency scanning, container image scanning, and the principle of least privilege applied to every service account and API key you create along the way. This isn't a separate "security stage" you do once at the end — it should already be threaded through everything from Stage 3 onward. I'm calling it out explicitly here because it's the stage most self-taught roadmaps skip entirely until something goes wrong.
What actually separates people who "know DevOps tools" from people who are good at DevOps
Tool familiarity is necessary but not sufficient. The real skill is systems thinking under failure: when a deploy goes wrong at 2am, can you reason about what changed, isolate the blast radius, and roll back safely — or do you start trying things and hoping? That instinct comes from genuinely understanding the layers underneath the tools (which is why Stage 1 isn't optional, no matter how tempting it is to skip straight to Kubernetes), not from memorizing command flags.
A realistic timeline
For someone working through this alongside a full-time job, six to twelve months to genuine competence across Stages 1–5 is realistic if you're deliberate about it — not by cramming, but by applying each stage to something real (even a personal project) before moving to the next. Stages 6–8 keep deepening for years; nobody "finishes" observability or security, they just get better at it. Treat this as a roadmap for direction, not a checklist to complete and file away.
Frequently asked questions
Do I need a computer science degree to move into DevOps? No. Most of what matters in this roadmap — Linux fundamentals, networking, scripting, the tools themselves — is learnable without one, and plenty of working DevOps engineers came from sysadmin, support, or self-taught backgrounds. A CS degree can help with certain deeper topics (distributed systems theory, for instance), but it's not a gate. What actually matters is demonstrable, hands-on competence at each stage above, not credentials.
Should I learn Kubernetes before I have a job that uses it? Learn it far enough to genuinely understand the core concepts (Stage 4 above) — that's valuable regardless of whether your current job uses it, since the mental model transfers. But don't feel obligated to become a Kubernetes expert speculatively; depth there is best built on a real system with real constraints, which is hard to fully replicate in a home lab. Comfortable-but-not-expert is a reasonable place to be before your first DevOps-titled role.
Is it worth getting a certification (AWS, Kubernetes, etc.)? Certifications can help get a resume past an initial screen, especially early in a career transition, and studying for one can be a useful forcing function to cover material systematically. But they're a supplement to the roadmap above, not a substitute for it — a certification without the hands-on troubleshooting instinct described in this article won't hold up in an actual incident, and interviewers who've been burned by "certified but can't debug anything real" candidates tend to probe for exactly that gap.
How is this different from a "site reliability engineer" (SRE) role? There's real overlap, and the distinction varies by company more than it should. Roughly: DevOps as a discipline is about the practices and culture connecting development and operations (this roadmap); SRE is a specific, more formalized approach to reliability that originated at Google, with more emphasis on error budgets, formal incident response processes, and treating operations problems as software engineering problems. In practice, plenty of "DevOps Engineer" job postings describe SRE work and vice versa — focus on the actual responsibilities listed, not the title.
What's the single highest-leverage thing to learn first if I only have a few hours a week? Linux fundamentals and shell comfort (Stage 1). Everything later in this roadmap assumes that foundation, and being shaky on it is the most common reason people plateau when they try to jump straight to Kubernetes or CI/CD tooling — the tools stop making sense the moment something goes wrong underneath them.
Where to actually start this week
If you're reading this and unsure where you personally sit on this roadmap: pick the earliest stage where you'd genuinely struggle to explain a concept to someone else, not the latest tool name you recognize. That's honest self-assessment, and it's a far better starting point than jumping straight to Kubernetes because it's the name everyone mentions in job postings.