Topics of Systems Administration
-
@EddieJennings one of the dangers or factors here is that enterprise system administration (pure SA) and "small business generalist IT" often share the title of SA with almost no overlapping duties. As a small business generalist, we'd see SA tasks, along with email, web, LOB apps, networking and countless other duties. In a pure SA role, we almost never do.
So from an SMB perspective, we think of the SA as the person that, for example, manages SQL Server. But to Microsoft and IT shops that have roles, that's a DBA role. The SA simply provides the OS for the DBA to work from. The SA likely would install SQL Server, but configuration and tuning is for the DBA. Same for Exchange, the SA might install the OS and maybe even Exchange, but the Exchange Admin does all the email tuning and setup. And on and on. The roles are very discrete and the SA only does SA tasks.
In the SMB, you can pick any role (web admin, email admin, DBA, network engineer) and say that they do "all the other things", because in the SMB it's always a generalist, never one of those specific roles. That we often call all those roles SA rather than randomly another one (and network engineer gets picked next most often) is mostly just because it's the words most easily consumed by management and little else.
In my SMB experience, SA work is not even the predominant role when working on servers. It's LOB management.
-
@EddieJennings said in Topics of Systems Administration:
I do see your dilemma. However, I have yet to see a system admin not be expected to have some of the aforementioned knowledge. Perhaps my new gig will be the first.
Well, you could define SA as being a role that doesn't need that knowledge and if you see anything else, it's not SA.
SAs are expected to be bright and knowledgeable, but there's a big difference between being expected to be able to figure out everyone elses' jobs, and their jobs being part of your job.
SA is a lot like being a lawyer. Your attorney's job is not to make business decisions for you, it's to know the law. But loads and loads of lawyers (like most of them) end up business consulting because they tend to be smarter than average, have more exposure, know now to think about things better, and take a serious interest in business. It's not their role and we don't even confuse it for being so, but if we treated them like we did in IT, we'd start calling nearly every business function a "legal issue."
-
@EddieJennings said in Topics of Systems Administration:
As far as drawing the lines, that's always though. I do think the answer must lie within the overall target audience and how comprehensive the information ought to be. Perhaps one line can be found by deciding if the book should appeal to the average system admin that has to do non-system tasks or the system admin that would never do non-system tasks.
Well there are two options.... targeting people wanting to learn about system administration, or targeting people who want to learn something that isn't system administration, but want it to be called system administration, and aren't looking in the right place.
Think about it in terms of any other topic. We ask "What do you need to know to do X" and the answer is "Well that depends if you want them to do X or Y?"
Well, that they wanted X was the sole premise, how does Y come into play, ever?
Topic: "How to ride a bicycle"
But then: "Maybe we should teach driving a car and boat safety primarily."What?
-
@scottalanmiller said in Topics of Systems Administration:
@stacksofplates said in Topics of Systems Administration:
@scottalanmiller said in Topics of Systems Administration:
That handbook is also associated with LISA, that totally out of touch and incompetent (and not to be seen anywhere in the real world) group that claims to oversee systems administration and traditionally defined the scale of administration by the ridiculous concepts of "user account count" and "code compilation".
Like systems such as Amazon or Change.org or Facebook or Google were all "small time, low level" admin shops because they don't create millions of users at the OS level.
Not sure what you mean here. Looking at the programs over the last 10 years (the 4th edition of the book was released in 2010) LISA has been about DevOps principles, containers, security, etc. Is backed by Amazon, Facebook, Netflix, etc and a good number of the speakers are from those companies.
This is weird, but Wikipedia says that they announced four years ago that LISA was going away.
And this is all that there is for a website, so seems likely...
Their last salary survey was 2011 (which I had seen in 2011.)
https://www.usenix.org/conferences/byname/5
There's one scheduled for next year.
-
@scottalanmiller said in Topics of Systems Administration:
@EddieJennings one of the dangers or factors here is that enterprise system administration (pure SA) and "small business generalist IT" often share the title of SA with almost no overlapping duties. As a small business generalist, we'd see SA tasks, along with email, web, LOB apps, networking and countless other duties. In a pure SA role, we almost never do.
This might be one of the lines for which you're looking. Perhaps specify in the book, that if you're working in a SMB, this book of pure system administration isn't intended for you.
So from an SMB perspective, we think of the SA as the person that, for example, manages SQL Server. But to Microsoft and IT shops that have roles, that's a DBA role. The SA simply provides the OS for the DBA to work from. The SA likely would install SQL Server, but configuration and tuning is for the DBA. Same for Exchange, the SA might install the OS and maybe even Exchange, but the Exchange Admin does all the email tuning and setup. And on and on. The roles are very discrete and the SA only does SA tasks.
In the SMB, you can pick any role (web admin, email admin, DBA, network engineer) and say that they do "all the other things", because in the SMB it's always a generalist, never one of those specific roles. That we often call all those roles SA rather than randomly another one (and network engineer gets picked next most often) is mostly just because it's the words most easily consumed by management and little else.
In my SMB experience, SA work is not even the predominant role when working on servers. It's LOB management.
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.
-
@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.
-
@scottalanmiller you are asking a group consisting of almost only SMB focused people.
To them, there is no such thing as this mythical System Admin that you continually talk about.
The responses above prove that.
Do most of them know the technical difference? Sure. Any that didn't when they started reading ML, would have had it beat in to them by now.
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.
-
@stacksofplates said in Topics of Systems Administration:
@scottalanmiller said in Topics of Systems Administration:
@stacksofplates said in Topics of Systems Administration:
@scottalanmiller said in Topics of Systems Administration:
That handbook is also associated with LISA, that totally out of touch and incompetent (and not to be seen anywhere in the real world) group that claims to oversee systems administration and traditionally defined the scale of administration by the ridiculous concepts of "user account count" and "code compilation".
Like systems such as Amazon or Change.org or Facebook or Google were all "small time, low level" admin shops because they don't create millions of users at the OS level.
Not sure what you mean here. Looking at the programs over the last 10 years (the 4th edition of the book was released in 2010) LISA has been about DevOps principles, containers, security, etc. Is backed by Amazon, Facebook, Netflix, etc and a good number of the speakers are from those companies.
This is weird, but Wikipedia says that they announced four years ago that LISA was going away.
And this is all that there is for a website, so seems likely...
Their last salary survey was 2011 (which I had seen in 2011.)
https://www.usenix.org/conferences/byname/5
There's one scheduled for next year.
LISA was an organization. The conference is a later thing that shares a name. I'm referencing the LISA organization that appears to no longer exist.
-
@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.
