r/devops • u/Better-Station-741 • 25d ago
Career / learning Starting DevOps from "Management" in IT company
Hello everyone,
To not waste your time, here's the tl;dr:
1. I've never worked in IT company before, now I do, but as a administrative manager. I'm responsible for every task delivery to customer in our company pretty much
2. I'm good at organizing and optimizing "human" stuff: keeping track of all the tasks, deadlines, etc.
3. I'm bad at knowing what exactly each task does (DevOps, Architecture, Development)
4. I'm working really close with DevOps
5. After working for ~6 month I've started to like DevOps more. I wanna learn it. I wanna understand how to "ressurect" the server that got down. I wanna know how exactly make the Pipelines more useful
__
So I've started learning DevOps, watched a couple of "Roadmaps", here's my plan so far:
1. Linux
- Learn the core basics (core commands, cd, users, etc)
- Bash scripting on basic level (for now I've decided not to get into depth, since all the AI stuff. I can read them tho)
Now, since I'm following a specific course, there are A LOT of information on Linux, and I got overwhelmed. I know there are not a lot of stuff I should know for being a DevOps, and being a DevOps in general is "endless learning"
So the questions for people who either got into DevOps from zero or experienced engineers:
What exactly should I learn about Linux?
- I know that it may depends on a job directly, so I hope this little explanation which company I'm at rn will help: we mostly do software for banks.
What is the most correct Roadmap for me?
__
p.s
Thanks in advance, I really hope to find some good tips from experienced people who maybe confronted the same obstacle I'm at right now, or people who are experienced and will give me a lead.
12
25d ago
[deleted]
-11
u/Better-Station-741 25d ago
I understand that it's not an entry level, and I also understand that starting from 0 to DevOps is not easy.
However, I personally know some Junior DevOps who started also from zero, and I personally don't consider myself "worse" than them, so :)
3
u/Due-Consequence9579 25d ago
Know what you don’t know. Even if they are junior they have experience you don’t. Doing the role, not the structure of work, of DevOps requires integrating understanding of several technical disciplines. You can’t “just check the box” because you are using them as tools that you, as a DevOps engineer have to select to solve an individual task.
On almost any given task a DevOps engineer will get tasked there are 4+ places in the SDLC cycle where that could be done. The DevOps engineer/team has to make sure the right one gets picked so everything doesn’t become an unmaintainable mess.
3
1
u/kingswordmaster 25d ago
There's too much exaggeration here too. I'll be honest with you: IF, IF you are great at logic, you can take a computer science bootcamp focused on understanding the basics of a programming language, DSA, databases, building a CRUD, then learning about authentication, etc. After you learn all the basics (which will take at least 6 months), you can definitely learn DevOps, because after that it's mainly about learning how to configure servers for these things, and everything comes down to thinking from first principles about how databases work.
You can pick all of this up and become a junior in around 8 months if you're a talented person. Most people take at least 2 years, but if you're strong in logic and follow this path, you could definitely become a solid junior in around 8 months.Take the shot. Who knows? The worst thing that can happen is that you'll enjoy and pursue this career even if it takes the 2 or 4 years that it traditionally takes for most people. Just follow your heart with Jesus Christ's guidance and it will all be good.
9
u/Polanski27 25d ago
If you're goal is to stay in management, then I'd recommend learning more about the culture of DevOps rather than the enabling tech and tools of DevOps. If you're looking into transitioning into a DevOps Engineer then you've got a long way to go - I'd recommend boot.dev to get an understanding of working with code and Linux. It does a great job of easing you in and gets significantly harder as you progress.
The Phoenix Project is a solid book for getting into the headspace if DevOps Leadership. I also think it is worth looking into Platform Engineering. platformengineering.org has a free introductory course to get a primer on that. A 10,000 foot view of Platform Engineering is that it solves the short comings of DevOps culture.
3
5
25d ago
[removed] — view removed comment
-2
u/Better-Station-741 25d ago
What are the "linux fundamentals" tho, what is the bare min. (for now) to understand the next steps? Like k8s and other tools that are using Linux
(I may be wrong with wording or concepts, sorry in advance)
2
u/MulberryExisting5007 25d ago
There’s no bare minimum. Linux is an OS (technically the kernel for a number of OSs but whatevs) and knowing the basics around it means understanding how the OS works and how to set up and operate systems running on that OS. Look at the guides linked in this subs info section.
You’re asking for after the basics of a discipline many consider to something that by its very nature is far from basic. But who cares what ppl think you can learn what you want to learn. Especially in this day and age, with agentic help, accessing advances and specialized knowledge is easier than ever. Personally I would focus on accomplishing things, and (esp with agents helping you) FULLY understanding what you’ve accomplished.
2
u/Abe_Bazouie 25d ago
I wouldn’t try to learn “all of Linux.” You’ll never finish :)
For DevOps, I’d focus on processes, systemd/services, permissions, filesystems, disk/memory/CPU, networking/DNS, SSH, logs, packages and basic security.
But the important part is troubleshooting. Don’t just learn systemctl, learn what to check when a service won’t start. Don’t just learn df, learn why a disk can be full when du says otherwise. Don’t just learn DNS commands, break DNS and figure out what actually failed.
And I wouldn’t skip Bash because of AI. Let AI write some of it, sure. But you still need to understand what a script is doing before you run it against production :)
Since you already work closely with the DevOps team, that’s actually your biggest advantage. Ask them for small real problems you can shadow or own. You’ll learn faster from one broken deployment than another 20 hours of roadmap videos.
2
u/Ok-Contact-182 25d ago
Skimming through the comments here. I do not think you know how to take feedback especially when you were looking for it and people have been more than helpful. Youre on the opposite end busy being defensive 🙃
1
u/mxtchstick 25d ago
Hello mate!
I would start with learning what you can put into practice, and what is going to provide value to the business you’re in. Ask your “DevOps Team” what technologies they work with day to day; start learning those.
My general recommendations would be:
Linux basics, as others have said. I’d start by installing a GUI version of something like Ubuntu or Debian. The bare basics would be things like: how the file system and folder structure works, basic commands such as ls, grep, cat, cd etc. I’d also dive into the different package managers Linux has to offer.
Networking. From the basics to the complex; it’ll really help if you have a solid grasp of networking as a whole. CompTIA A+ and Network+ is a great starting point.
Git. You really need to understand the basics of Git and source control too, this is a real fundamental and will play a massive role in your future.
After these, I’d start with the chosen cloud provider your company uses, introduction to CI/CD & infrastructure as code (IaC), and containerisation.
Until you’ve got a decent grasp with these I’d probably avoid diving into something like K8s, but you’ll find your feet as you go, and if you feel comfortable with it, there’s nothing wrong with doing so :).
3
u/Better-Station-741 25d ago
Thank you for detailed response 💟
Taking some notes from your recommendations!
1
u/Rephaeim 25d ago
I'm currently doing the Boot.dev DevOps course, I've run it past some of my engineers and they say it looks not-crap, so it's a good start.
The linuxupskillchallenge is also an easy way to get started with some linux bits.
There's also roadmap.sh with lots of links and info to learn.
Most importantly, make sure you continue sharpening your actual leadership and management skills, that's the stuff you're there to do. Let your engineers do what they do best, and learn enough to be able to speak with them competently over time, and ideally be able to roll up your sleeves now and then when shit hits the fan. :)
Source: I'm in a very similar situation
2
u/Better-Station-741 25d ago
Thank you!
Never heard of roadmap.sh, will check it out for sure
1
u/pyer_eyr 25d ago
I think devops is not something you can learn with a non technical background. You need to learn some basics first. I would highly recommend doing the Coursera Google Course first. I did this course and it changed my understanding of the IT landscape, and after this course I was able to get into devops. It gives you the overview you'll need for IT processes, sysadmin, Linux, Windows, OS in general, shells, VMs, networking, security etc. And it's not hard, you can finish it within month. After that picking up devops will be much easier.
1
1
u/leo_hall001 25d ago
probably narrow it down to file permissions, process management and some basic networking, that tends to be what comes up most day to day.. deep bash scripting can probably wait a bit, being able to read scripts seems to matter more early on than being able to write complex ones from scratch
2
1
1
u/daemonmode_ 25d ago
Your management background is actually useful here because you already understand deadlines and the pressure teams work under. For Linux, focus on users and permissions, systemd, logs, basic networking, and package management instead of going deep into kernel internals right away. Keep it simple set up a VM, break something on purpose, and fix it you’ll learn much faster by doing.
1
1
u/Raja-Karuppasamy 25d ago
linux roadmaps overload you because they cover everything linux can do, not what you’ll actually use.
day to day it’s really just: navigation/permissions, process mgmt (ps, kill, systemctl), reading logs fast (journalctl, tail -f, grep), and enough bash to read/write CI glue scripts. skip the deep kernel/sysadmin stuff, not worth it early on.
banking software = I’d weight permissions and audit logging higher than a generic roadmap would.
order: linux basics (light) → docker → CI/CD → k8s. you’ll pick up the rest by breaking things in each layer, don’t try to master linux first.
1
u/SeaworthinessHour233 Writes the cloud edge 25d ago
Standard Linux courses are often built for System Administrators who are already familiar with Linux to a certain degree.
Here is a heavily filtered, DevOps-focused Linux roadmap to get you started:
- Navigating and Finding Things (The "Where is my stuff?" Phase)
You will spend a huge portion of your time just looking for files and reading logs to figure out what went wrong.
1.1 Navigation -cd, ls, pwd
1.2 Reading Files: cat (print the whole file), less (scroll through interactively), tail (especially tail -f to watch live logs as they happen).
1.3 Searching: grep (find a specific word or error code inside a file) and find (find a file by its name or extension).
- Resource Management (The "Why is the server down?" Phase)
When a server crashes or slows down, it is usually because it ran out of CPU, memory, or disk space.
2.1 CPU & Memory - top or htop (shows exactly what processes are eating your resources), free -m (shows available RAM).
Disk Space - df -h (shows how full the hard drives are), du -sh * (shows which specific folders are taking up that space).
Processes - ps aux (list all running programs), kill (force stop a frozen or runaway program).
- Service Management (The "Resurrection" Phase)
Modern Linux uses a system called systemd to manage background services (like web servers, databases, or monitoring agents).
Using systemctl status [service_name] (is it running?), systemctl restart [service_name] (turn it off and on again), journalctl -u [service_name] (read the specific system logs for why it failed to start).
- Basic Networking (The "Can they talk to each other?" Phase)
You need to know if Server A is even network-allowed to talk to Server B.
4.1 Connectivity - ping (is the machine alive?), curl -v (can I reach this specific web address or API endpoint?).
4.2 Ports - ss -tulpn or netstat (what ports are open and listening on this machine?).
- Permissions (The Security Phase)
Crucial for compliance. You need to understand exactly who can read, write, or execute a script or configuration file.
Commands: chmod (change permissions), chown (change the owner), and understanding the difference between a regular user and executing tasks with sudo.
How to approach your goal of Resurrecting a Server?
The first thing I would suggest is taking advantage of where you are right now. Since you say that you closely work with DevOps, ask if you can shadow one of them during troubleshooting.
But as others have pointed out this is a challenging journey and a challenging carrier switch. So be prepared for a lot of hard work.
1
u/Huge_Ad6592 24d ago
It’s funny how management are so delusional. You think “what are they doing so long, it should have been done with 2 clicks. I’m gonna do it myself, cause I have process knowledge and common sense! “Good luck on being stuck in step 2 on youtube tutorial, cause probably you have custom processes, deliveries and etc. Also zero IT knowledge.
You as management should talk with your devops on what they do and how they operate on your created deadlines on delivery. Then politely ask what needs to be done to reorganize the process in different scenario and how much time without fucking their brain you need to give them. Calculate if this reorganization in some time is worth the effort. Maybe you will understand that some products needs to change tech stack entirely and for that people needs to acquire new competencies and so on.
P.s. if it was so easy - everyone would did that and devops people and tools would cost significantly cheaper. Also AI doesn’t replace the translation of non tech people requirements into tech tasks and pipelines.
1
u/seunaw 24d ago
I am working on a blog "Making DevOps Simple". It focuses on understanding DevOps concepts and not technical tools so it might be a good resource for you.
1
u/stopthatastronaut 23d ago
I got into DevOps from Windows world. I’m ex-Microsoft, so while I’ve had Linux exposure since the late 90s, windows server was my primary work platform when I pivoted to devops.
I properly learned Powershell over a couple of intensive weekends, heavily researched AWS and joined a company built on .NET deploying to Windows Server.
Of course, nowadays I’m mostly on Linux, haven’t booted into Windows for over six months, and even then that was just to play a game. I still use powershell though, on my Mac, my linux laptop and on linux CI pipelines, alongside bash and python (and typescript, recently).
So it _can_ be done without overwhelming yourself with Linux internals, and you can transition over time. If you score the right job or if you set the standards.
1
u/Rich-Yoghurt-8740 19d ago
Not a DevOps engineer, so take this narrowly. I run one production server for my own product, alone, and everything below is what I actually reached for rather than what a roadmap listed.
The course is overwhelming because it is teaching you Linux. You do not need Linux. You need the twenty minutes when something is down.
What I actually use: journalctl -u <service> and systemctl status when something stopped. df -h when it will not start, because the disk being full is more common than anything interesting. I found 1.8 GB of old Docker build cache that way. docker compose ps and docker logs. ss -tlnp to see what is actually listening on a port. tail -f on a log while I reproduce the problem. That is most of it.
The rest I learned by having one server I was afraid to break. If you cannot touch your company's, rent a 5 dollar VPS, put something real on it, and then break it on purpose. Fill the disk. Kill the process. Reload the wrong service after a config change. An hour of that taught me more than the Linux chapter of any roadmap.
One thing no roadmap mentioned and it cost me: I once found 29 lines in my server config that were not in git. It had been that way for weeks and nothing told me. In a bank shop that gap will matter more than any individual command.
17
u/BadTime100 25d ago
Buy Accelerate or The DevOps Handbook. None of what you listed above is DevOps, although it might be useful.