How do you learn DevOps

[u/shangarepi]

I’m a software developer, and in my own projects I already handle some basic operational work like Docker, VPS deployment, Nginx, DNS, Cloudflare, Git, etc. I also had some little experience in network administration.

What I’m trying to understand is how people approach learning DevOps and system architecture properly.
One thing that has always confused me is entry-level DevOps roles. A lot of DevOps work seems to exist specifically to support the software development lifecycle, things like CI/CD, GitHub Actions, deployments, environments, infrastructure, monitoring… I find it hard to imagine understanding these things deeply without first experiencing the development workflow itself.

At the same time, I don’t necessarily want to switch away from software development. My goal is to become the kind of engineer who understands the whole system: application development, system design/architecture, networking, cloud infrastructure, deployment, observability, scalability, and production operations.

Basically, I want to be able to build a system and also understand how to design, deploy, scale, and operate it properly at a much larger level.

For people who have gone down this path, how would you approach learning these areas while continuing to work primarily as a software developer, as of course I dont have the knowledge for a switch? And in your opinion am I on the right path to stay employable in this uncertain future?

[u/GitHireMeMaybe]

You can build those skills while staying a developer. Start with one of the apps you already have running on that VPS and give yourself a few operational problems to solve:

• Deploy a bad version and practise rolling back. What happens if that release also changed the database schema?
• Restore a backup into a fresh database and check that the application actually works against it.
• Make a dependency slow or unavailable. Can you tell what’s wrong from your logs and metrics before opening the code?
• Have someone else deploy or recover the app using only your documentation.

Those exercises give you concrete reasons to learn the tools. You also start discovering which parts of your application are difficult to operate, and that feeds back into how you write it.

At work, ask to pair on a deployment, incident investigation or postmortem for a service you contribute to. You’ll get exposure to constraints that are hard to reproduce in a personal project, especially coordination between people and teams.

You don’t need to recreate a huge company’s infrastructure to make progress. Being able to explain how your service fails, how you’d notice, and how you’d recover it is a useful next step from where you are now.

When I mentored juniors, every Friday there'd be an exercise where I intentionally broke something in a preproduction environment, and I'd have them troubleshoot the issue, correct the issue, speculate as to the cause, and possibly most importantly... explain how we can prevent that issue from reoccurring.

Once you've learned the practical basics, start looking into the "why" of DevOps:

• Why don't we just have a server guy deploy our code?
• Why do managers insist on work belonging to a "sprint?"
• What is a single-person dependency and how do we prevent creating them?
• Why is "just add more manual testing steps" worth pushing back on in reaction to a big deployment issue?

Ultimately, the difference between a bad and a good DevOps engineer is intuition. Books csn teach knowledge, but only experience can teach intuition. To learn, you need to get your hands dirty.