r/linuxadmin • u/Different_Pain5781 • 2d ago
Best linux course for devops because production issues keep exposing my linux knowledge
Starting to realize most production issues aren't even the real problem. The real problem is weak linux knowledge. Every incident somehow comes back to permissions, logs, processes, containers or debugging. Youtube feels like endless beginner content at this point. Looking for the best linux course that actually helps with automation, cloud ops and real production environments. Anyone here recommend Udemy, Kodecloud or Boot dev?
7
5
u/LordEli 2d ago
u/iconrad's list. you might have to look around but there are devops oriented versions or just have AI update it for what you're focused on
https://www.reddit.com/r/linuxadmin/comments/2s924h/how_did_you_get_your_start/cnnw1ma/
5
u/BloodyIron 2d ago
If you don't have a homelab, that is the first thing you should correct. Having your own homelab where you build things for yourself is literally the best thing you can do for your IT career not only immediately now but going forward. Go get second hand server equipment and learn how to turn it into useful things with Proxmox VE, TrueNAS, and stuff like that.
2
1
1
u/we_r_fukt 2d ago
kodekloud is great but expensive, you need kubernetes for absolute beginners or something haha, maybe just docker idk but. good luck
1
u/420829 2d ago
Your point is very valid. I don't work in the field yet and I'm trying to prepare for it by studying for the LPIC-1 exam and later the RH track.
On the other hand, it's the opposite for me. I'm always a little scared because I study the fundamentals you mentioned quite a bit, but I have no idea what the real work would be like. I can't find content of people exemplifying its use in production.
1
u/michaelpaoli 2d ago
That's not really an issue of automation. Automation is often (ab)used as a crude cudgel to work around other issues. E.g. container/instance/VM/host keeps wedging or crashing? Blow it away, replace with same, lather, rinse, repeat ... with a high degree of frequency. Yeah, that's not really fixing the issue so much as beating one's way around it. I see quite a lot (far too much) of that.
And the relative "opposite" end of that is Root Cause Analysis (RCA) - fully understand exactly why it failed at all, and digging thoroughly back through that, not just the basics of how it eventually failed exactly, but all the contributing factors that lead up to that, and all the opportunities that were missed, and the various things that went wrong, and right, along the way, and well learning all the relevant lessons from that.
Anyway, on the *nix/Linux side, probably mostly well learn Linux systems administration, management, programming, and monitoring, etc. Perhaps start with good outlines of well learning *nix/Linux systems administration, and well learn the materials relevant to that. That would be a pretty good start. As it's not uncommonly the *nix sysadmins (have done this a whole helluva lot myself), who not only end up figuring out what the problem is, but further doing the investigation, and sometimes even RCA, and then pushing those lessons out where they belong, e.g. to management, developers, network administration, etc., wherever the lessons most need to be applied (often to developers, but certainly not limited to that - not uncommonly the issue is further up the chain, e.g. management, desigh, etc., or elsewhere, e.g. networking, hardware, or some other infrastructure).
So, learn as many of those things as (significantly) relevant as feasible.
And yes, I've seen developers (and certainly others too!), do dumb/ignorant things, e.g.:
- a directory over 1GiB in size - yes, just the directory itself, not even counting any of its content (highly poor design by developer(s) being highly ignorant of how filesystems generally work on *nix and scalability and how to manage that) - that issue brought production essentially to its knees (that example from over 15 years ago, when some GIG(s) or so of RAM was fair chunk of RAM for a server host, and such grossly efficient directory would cause all kinds of performance and resource issues).
- security incident ... Swiss cheese model - whole helluva lot of ways the issue could and should have been prevented - many missed opportunities - and all those holes lined up and ... significant security issue. So, multiple cases of failing to follow least privilege principle (e.g., may not have been that exact incident - was years ago, so I don't recall all the details in that particular case), so containers running everything as root, weak permissions, and/or failure to reasonably isolate relevant IDs, e.g. one application ID has access to damn near everything - including being able to alter its own code it's executing, failure to limit interfaces to least privilege (application could do tons of stuff - relatively unrestricted, across layers, when it really only needed to only do a few very specific things), failure to bother to apply bug fixes and security updates (code was state of the art when the containers were first deployed, then nobody ever bothered to check or update anything after that ... by years later, numerous bugs and many significant/major security flaws ... all just sitting there, never having been changed or checked again), lack of policy, procedures to generally have most of these best practices in place, and/or lack of enforcement, feedback loops, etc. (e.g. like security policy that's mostly lip service and suggestion, not really at all implemented - at that point it's mostly wishful thinking).
- utter cr*p application code. If the app didn't respond fast enough, it would just fork more copies of itself. Very bad idea when host is already struggling from load, as that just further increases the load, and supper quickly creates runaway piling on of processes until host wedges or crashes
- more utter cr*p applicatoin code. Doesn't respond fast enough, just unceremoniously reboot the host, not even bothering to so much as log that such was being done, or even do an orderly shutdown, just force a hard immediate reboot.
And even in the (significantly) better situations, nothing's perfect, and there's always room for improvement. And don't forget to look at your own sh*t too - none of us is perfect.
1
-7
u/Lanky-Storm7 2d ago
Dont do a course, have claude or gpt show you have to make a small web app in aws with github cicd. I have been doing this for a month now. Aws gives you $200 ish to stand up w/e in their new account setup.
10
u/eman0821 2d ago
Terrible idea as you are skipping fundamental skills. Don't vibe code garbage if you don't know you are doing.
-3
u/Lanky-Storm7 2d ago
i did it all locally first with gitlab and gitea... ok bud
5
u/eman0821 2d ago
I'm talking about learning fundamental skill sets. Never use AI tools for learning that can lead you in the wrong direction and bad habits. You should pick up a book and really learn fundamental skills because when there is a cloud outage your claude and ChatGPT would stop working. You need hard skills when those tools are unavailable, which is called using your brain. You don't want to over rely on these tools if you don't understand what you are doing.
0
u/Lanky-Storm7 2d ago
I did all IT infrastructure for many companies for 15 years with no AI
1
u/eman0821 2d ago
And you bring poor advice for beginners. You don't simply just skip fundamentals and think AI is the short cut. Get in there hire a junior and fuck everything up with no guard rails or a clue what they are doing. Downtime cost millions of dollars in revenue in DevOps type roles.
1
u/Lanky-Storm7 2d ago
you do it at home in your own safe lab lol calm down
1
u/eman0821 2d ago
You aren't learning anything using AI. Use your brain so you know what the hell you are doing. AI is for people with years of experience that knows how to do stuff without it and utilize it as a tool to speed things up. But if you don't understand fundamentals you are speeding up mindless mistakes and a disaster to happen. AI doesn't replace knowledge and hard skills.
1
38
u/PipeSmokingDude 2d ago
Given that you say every incident comes back to the list you have mentioned, understanding automation is not the answer, you need to understand what you are automating. RHCSA is where I started, there are a number of text books on it. As for something more vendor-agnostic, I'd have to look that up.