Topics of Systems Administration
-
@EddieJennings said in Topics of Systems Administration:
This I understand. In my last gig, we were organized like that for our database needs. We (Systems Team) provided the VMs for the DBAs to do what they needed to do for SQL Server. We also had a dedicated networking and telecom team. But for Systems Team, we were all SMB generalists that had to function as "SMEs" for certain applications -- like Exchange for me.
Right, so it wasn't a systems team. There was telecom, DBA, networking, and generalists. Nothing wrong with that, but it's important to understand what it is.
The payscales of generalists and SAs are wildly different, as are their daily tasks.
-
@JaredBusch said in Topics of Systems Administration:
But that doesn't mean a damned thing to them, because there is no such thing as a "Systems Administrator" that is actually an administrator of systems.
Even in the SMB (under 20 people even) we have customers that use real SA. Where SA and App teams are separate companies. One is pure Windows Server, the other is pure application and they call each other to coordinate. The app team has only a light knowledge of Windows, not enough to run it in production. And the Windows team knows extremely little about the workings of the application.
I see this commonly in manufacturing, for example. And in medical as well.
-
@JaredBusch said in Topics of Systems Administration:
To them, there is no such thing as this mythical System Admin that you continually talk about.
I have faith that one day I might spot one. I'll then have to decide if I should try to slay it to harvest the blood. Even at the cost of a half-life, it might be worth it.
-
What's super odd to me is that Microsoft through their certifications really did a great job of codifying the roles, they made the tasks very clear with email, web, databases, proxies, and other functions very clearly split out into separate exams and career paths. But in the UNIX world (where many of those applications are commonly bundled with the OS) they often taught it very muddied without clear differentiation in most industry material about why some random applications were deemed SA tasks and others not.
But in the real world, it's super common to find real UNIX SAs, but Windows ones nearly never exist.
-
@EddieJennings funny enough, working for a shop that you used to work for.... we have things split like this. The OS is handled by one team and there is no access to the application(s) on top. The apps are handled by an app (dev) team, and the OS by a systems team.
-
@scottalanmiller said in Topics of Systems Administration:
@EddieJennings said in Topics of Systems Administration:
@scottalanmiller said in Topics of Systems Administration:
@EddieJennings said in Topics of Systems Administration:
@scottalanmiller said in Topics of Systems Administration:
I agree that broader concepts matter. But is an SA book a good place to teach network protocols? Should a networking book or an email book do that instead?
I'm sure this will get a laugh from you, but I don't recall any of my CCNA books (even the networking fundamentals) mentioning DNS, SMTP, and other network protocols.
I'm pretty sure that they do, lol. The Net+ definitely does. That's where that stuff really goes, definitely not in a systems book.
It would be super high level of course. Digging into SMTP makes no sense until you are a deep email expert. Even full time email admins rarely know much about SMTP beyond the very basics. For other roles to know much would be unproductive. Knowing that it's the protocol of email is really enough.
I will admit a bit of bias in my feeling of the importance of needing to know a bit about SMTP as my last two jobs have ended with me being the primary (in one case, only) E-mail administrator
I have a similar, but opposite bias. Back in the 90s I read like every major book on SA you can imagine. They all covered pretty much the same stuff. And then, in a career where I've worked in everything from SMB to three Fortune 10s, in academia, have taught both university and professional classes (I was the SA teacher for IBM and Lockheed), have overseen hundreds of high price admins.... never once in decades of experience have I encountered any role that in any way resembled what every book and reference touted as "what SAs do."
They all seem to have worked in a tiny subsection of 1980s or 1990s SMBs, done just one or two essentially similar tasks, and just assumed that the entire field was what they saw without the slightest general experience. I assume that somewhere there was a professor who never managed to get a job in the field and a number of their students kept regurgitating the same false info.
And it would vary from minor (they all taught Sendmail, but Postfix is what almost all real world deployments were) to major (they all taught GUIs and printers, but find a UNIX shop that uses either, anywhere.) And it was giant percentages of the books, like 60-80%, focused on tasks I've never seen anywhere, in any industry, at any size, at any point in time - and almost all are ones I couldn't imagine having any scale.
And, of course, it all comes at the expense of learning the basics and actual material. I assume because it's easy to teach Sendmail basics and hard to teach real SA concepts. One is just copying common commands, the other is explaining difficult ideas. It has felt like they've always been a crutch, a way to cheap out on teaching what matters but make books long and daunting with little effort.
How did you teach classes for Lockheed when you only worked there for a week?
-
@scottalanmiller said in Topics of Systems Administration:
It's great stuff to know, but if we are approaching SA as a role, should we really teach all the application specific skills on top? And if so, why these and why not loads of databases, printers, directory servers, web servers, WordPress and so on? How do we pick which applications to teach and which to expect people to learn separately?
Experience is the only teacher here. A book or online training will only teach you a very small portion of your jobs throughout your career.
I agree with @JaredBusch. I've never seen this unicorn SA position you've always talked about. I've worked in a few enterprises, SMB, and for software companies. I have never seen a SA making $400k that never touches anything outside the OS.
-
@IRJ said in Topics of Systems Administration:
@scottalanmiller said in Topics of Systems Administration:
It's great stuff to know, but if we are approaching SA as a role, should we really teach all the application specific skills on top? And if so, why these and why not loads of databases, printers, directory servers, web servers, WordPress and so on? How do we pick which applications to teach and which to expect people to learn separately?
Experience is the only teacher here. A book or online training will only teach you a very small portion of your jobs throughout your career.
I agree with @JaredBusch. I've never seen this unicorn SA position you've always talked about. I've worked in a few enterprises, SMB, and for software companies. I have never seen a SA making $400k that never touches anything outside the OS.
Samesies.
-
@scottalanmiller said in Topics of Systems Administration:
In my SMB experience, SA work is not even the predominant role when working on servers. It's LOB management.
Now a book on application management concepts would be interesting.
-
Time to start calling ourselves Full Stack Administrators
-
@IRJ said in Topics of Systems Administration:
I have never seen a SA making $400k that never touches anything outside the OS.
I've seen the opposite. It's the real SAs that make that money (as do some other roles), but never the "just whatever" positions.
-
@flaxking said in Topics of Systems Administration:
@scottalanmiller said in Topics of Systems Administration:
In my SMB experience, SA work is not even the predominant role when working on servers. It's LOB management.
Now a book on application management concepts would be interesting.
It would be, fo sho. The challenge there would be picking a stack or app. Like... WordPress on Apache with MariaDB would be one. That could make sense.
QuickBooks on Windows 2019. That could work (but pretty simple.)
It's extremely hard to do anything general as each app is generally extremely unique. Even two PHP apps can be wildly different to the point of not being able to recognize them as related.
-
@IRJ said in Topics of Systems Administration:
Experience is the only teacher here. A book or online training will only teach you a very small portion of your jobs throughout your career.
Definitely, but there is a difference between a book that doesn't even know the field and one that gives you something to work from. I think too much of the industry has left discovering stuff to chance and little is known across corporate barriers.
-
@IRJ said in Topics of Systems Administration:
I agree with @JaredBusch. I've never seen this unicorn SA position you've always talked about.
What blows my mind is that I've known literally thousands of them. Many more of generalists, often with titles that don't reflect what they do. But real admins where 95%+ of their real work (discounting meetings, water cooler convoes, classes and the like) is systems... absolutely. Now of course, I've been in single departments with massive teams all in one place. So it adds up quickly. But in knowing those people, our experience spread across company after company and it was the same everywhere that they came from and went to.
-
My first IT job (not software) was as a junior UNIX admin, pure admin, in 1994. Working for the "senior" (who was pretty junior himself I'm guessing looking back) who was also a pure admin. That was my first introduction to it.
By 1999 was doing pure admin on Windows. In 2000, mixed Windows and Linux with just the tiniest addition of application stack (roughly LAMP stack), but the role was nearly all OS.
IBM in 2000 was my first major place where they operated as little SMB silos and while SA was a major part of the day, it was very far from all of it and I had to cover absolutely everything including both CIO and CTO hats. So IBM was about the polar opposite of pure SA.
Worked for Microsoft and Dell in a pure SA role in 2004 and 2005. Then Wall St., pure SA there. Then hedge fund row, same thing. Then non-profit in San Fran, definitely pure SA as well.
IBM certainly felt like the outlier with loads of disorganization and low efficiency. And it showed, they had to close the entire facility for exactly those reasons. From little ten person companies to fortune 10, from grocery to wildly different finance to medical to non-profits.
I'm not saying it's the norm, it's obviously not. But "norm" is weird to define when the alternative is "not-SA". LOL But if we use "companies" as the base number, maybe 1% of companies, at most, will reasonable try to have a real SA role. But then again, only 1% of companies is big enough to have value to it. But those that do, hire a lot and pay a lot.
-
@stacksofplates said in Topics of Systems Administration:
I have never seen a SA making $400k that never touches anything outside the OS.
Well, you've also said that you've never seen one at all, so this doesn't tell us anything additional. When I've seen roles in IT making over $400K, it's been either because they wear multiple hats and it's generally manager roles that cause the pay increase, or it's from being pure SA. From what I've seen, pure SA is the highest paid IT technical role with any volume to it.
My guess is, once you see pure SA you tend to see it a bit. And when you do see it, and rule out the things called that but clearly aren't, I bet you find (and I truly bet, because there's definitely no data on this) that the average salaries are crazy, like averages well over $150K in the US. Whereas the job by title, rather than responsibility, is like half that or less.
-
@scottalanmiller said in Topics of Systems Administration:
@flaxking said in Topics of Systems Administration:
@scottalanmiller said in Topics of Systems Administration:
In my SMB experience, SA work is not even the predominant role when working on servers. It's LOB management.
Now a book on application management concepts would be interesting.
It would be, fo sho. The challenge there would be picking a stack or app. Like... WordPress on Apache with MariaDB would be one. That could make sense.
QuickBooks on Windows 2019. That could work (but pretty simple.)
It's extremely hard to do anything general as each app is generally extremely unique. Even two PHP apps can be wildly different to the point of not being able to recognize them as related.
I've feel like you're seeing the same challenge people had with writing sysadmin books.
An app managed by an experience IT generalist and one managed by say the manager of some department look setup very differently in my opinion. I believe the way the IT generalist approaches any app and sets it up could be outlined. Though it would probably have to use examples of things that of course won't be available or applicable in every app.
-
@flaxking said in Topics of Systems Administration:
@scottalanmiller said in Topics of Systems Administration:
@flaxking said in Topics of Systems Administration:
@scottalanmiller said in Topics of Systems Administration:
In my SMB experience, SA work is not even the predominant role when working on servers. It's LOB management.
Now a book on application management concepts would be interesting.
It would be, fo sho. The challenge there would be picking a stack or app. Like... WordPress on Apache with MariaDB would be one. That could make sense.
QuickBooks on Windows 2019. That could work (but pretty simple.)
It's extremely hard to do anything general as each app is generally extremely unique. Even two PHP apps can be wildly different to the point of not being able to recognize them as related.
I've feel like you're seeing the same challenge people had with writing sysadmin books.
An app managed by an experience IT generalist and one managed by say the manager of some department look setup very differently in my opinion. I believe the way the IT generalist approaches any app and sets it up could be outlined. Though it would probably have to use examples of things that of course won't be available or applicable in every app.
Something like.... deployment strategies for apps, like taking a piece from the architecture side of things.... now that could be interesting. Like: when do you use a database, a local database management system, or a remote database management system. High availability strategies (platform, application, etc.)
-
Troubleshooting v Reimage.
I don't know about you folk but where something is broken and the estimate is more than one hour to fix, we just reimage as it is faster and brings the machine to a known good state - providing not a hardware issue. Any book should cover something similar as I have seen lots of IT folk spend days on a problem (read, money), where they should just reimage.
-
