I totally agree with you. A part of my duties is setting up logging from AWS to Splunk and there's so many gotchas and stumbling blocks that's it's infuriating to even attempt and follow best practices.
A great example is Cloudtrail. The best practice is to send your OrgTrail (an org-wide Cloudtrail) to a separate account for security reasons. Cool. Okay, sounds easy enough. The Splunk docs are useless for AWS, so consulting with YouTube, Reddit, etc is the go-to for this.
It's so much easier to just leave the OrgTrail logging into the management account it's not even funny.
Looking forward to give this a spin at home to see if it'll be the future of non-RH based linux servers, although it'll take a long time before people are willing to throw it in prod like they do with CentOS. No way to change that except time.
Also it's interesting that some people defined Rocky as being 'unstable' when others read it as being 'solid as a rock'.
Technical problems aren't the primary reason people recommend against using Oracle, it's the extortion that happens further down the road once they've got you locked in. And in the case of Oracle Linux, that seems to be almost a certainty at some point.
As a non-developer whose code would probably make your average SRE's brain implode, how competent would this 'course' make me?
I started my IT career 2 years ago and my programming isn't that strong. I got pinged for a SRE job recently (my background so far is very much Linux based so I must have matched some filter) but I'm not strong in development, k8s (or even containers), or all of the other cool stuff I see on HN. I know I can lab stuff out, but that's not anywhere close to doing it live.
I don't want to be a SRE for Google, but I'd like to learn some more on the reliability side of my world and bring things like Git, Puppet, System design, etc and not be left behind in this wave that's approaching. My organization isn't too involved in the cloud, so a lot of upcoming tech seems out of reach.
I'm a little confused by the other responses you're getting here. I don't have these kinds of expectations for recent college grads. The breadth of the document is impressive to me, and as someone with decades of technical experience, I see plenty that I could brush up on. And the Linux basics section seems to do a pretty good job of starting from foundations. It's a bunch of the things I had to figure out myself starting at a command line with little to no help.
I wouldn't treat this as a course to be completed. Think of it as a guide, or a map, on your journey to getting smarter about tech. And it's a lifelong journey. Don't let anybody here convinced you that you're supposed to know everything, because technology is so complex at this point that nobody knows all of it. Just keep broadening your skills, and deepening them where you are passionate, and you will build yourself an enjoyable and productive career.
Unless you already know this really well, I'd start even at a more fundamental level than what is suggested by LinkedIn. I'd try learning Unix and a little bit of C by using The Unix Programming Environment by Kerninghan & Pike plus Kerninghan & Ritchie. It's quite timeless. Files, pipes, pointers, etc. That's the plumbing of software engineering.
Then also learn the calculus of software engineering: Logic. A good short intro is Huth & Ryan. The book covers some advanced topics in later chapters, but you don't need that if you don't want to. Logic is also timeless, and very practical. You can gain the ability to model check things, which is really really cool and used pretty often for e.g. distributed systems. This can unlock many cool positions for you.
Logic can also take you to logic and declarative programming. Something also worth investing into, and pretty addictive. For that, there's nothing better than The Art of Prolog.
This was solid advice. I've been wanting to move into the CTI space and I haven't come across too many tips that break down writing an effective executive summary.
1. Have a problem statement: What is wrong from a business perspective. Example: Password are unencrypted which dramatically increases risk of class-action lawsuits.
2. Have a list of corrective controls: Staff training, audits, technical controls
3. Cost statement: X control costs $Y.
4. Risk analysis: Problem reduced by 43%.
5. Summary statement: Execute this, it pays for itself.
Bear in mind an executive summary is either superficial or its a lie. You need to have a real technical report behind the executive summary so that it isn't a lie.
I went from a manual machinist, meaning working with lathes and mills from WWII, to a career in Cybersecurity. During that transition I was also a plumber.
The 'simple life' jobs are also taxing, but just in different ways. Bosses yelling at you to get work done ASAP, union bullshit, and reletivly low pay (unless you own your own business).
While there are some days I wish I was doing some head math and watching a lathe make cuts on a electric motor shaft, in the end I'm happy with where I ended up.
Just posted this so you know that the grass isn't always greener 100% of the time!
In school for welding while also working at the machine shop. Making ~10.20/hr machining parts to repair electric motors. I start thinking about my future a bit more as I was making money (lol @ me thinking 10.20/hr was money but I was 19 and working more than I ever did). I started thinking about the doomsday scenarios where if this machine shop closed down, what would I do? The world was going more toward CNC machining. While today there is a place for a manual machinist, what place will it have when I'm 50? This fact, alongside the fact I could make more at Arby's, led me to quit.
I decided to give another trade a shot, which was plumbing. A family friend was a solo plumber and I inquired about being a helping hand. I enjoyed the work, but my boss wasn't exactly pleasant to work for. I got a decent pay raise in comparison to my last job, but exactly 0 vacation or benefits. In the beginning I was fine with this as he was 'doing me a favor' by showing me the ropes, but in the end it didn't work out.
When that job was winding down, I decided to go back to school for computers. I built computers in my day and I knew my way around which led me to pick this 'trade' up next. I started applying for L1 help desk jobs and got in with this company doing internal IT. Very thankful I ended up here as it was NOT a call center. We fielded maybe 10 calls a day, sometimes we had as little as 2, so I had a lot of downtime to study up on the next role. I signed up for LinuxAcademy and grinded courses.
LinuxAcademy has cloud servers, where I learned Linux on. The corporate security team caught that (oops), which is where I met them. Eventually they had an opening for a SecOps Analyst and now I'm here :).
THIS is the proper path to becoming a crusty, crotchety, greybeard. Self taught. Pulled up by your boot-straps. Doing it because you like it, not just because of $$$.
If I'm understanding you correctly and reading a bit between the lines, you'd recommend a move toward either a new product (within the same space?) or take a bigger drink of the Splunk kool-aid and move on to architecture.
I noticed you didn't mention CTI at all. I ass-ume that you're recommending the Splunk Engineer side more (they can also get into architecture, so that fits your description)?
I recommend avoiding a role of "Splunk Engineer", particularly in the long term, mainly because it's a narrow role that is likely to become intolerably boring and limited quickly.
While Splunk is rather good, I don't think there is enough depth and value in being a Splunk expert to sustain a whole career (like being an expert of SAP or C++ or some popular DBMS).
CTI is one of the good uses you can apply Splunk and many more tools and methods to; if you want to be a CTI expert you should transcend your current Splunk focus, or you'll be the "hero" who keeps Splunk running despite budget problems and maintains the data sources and dashboards that someone actually important asks for.
A great example is Cloudtrail. The best practice is to send your OrgTrail (an org-wide Cloudtrail) to a separate account for security reasons. Cool. Okay, sounds easy enough. The Splunk docs are useless for AWS, so consulting with YouTube, Reddit, etc is the go-to for this.
It's so much easier to just leave the OrgTrail logging into the management account it's not even funny.