The OutRider Computing Journal

A free monthly column for users, administrators, programmers and hobbyists who use UNIXlike Operating Systems.

Home | Search | Site Map | Feedback | Subscriptions


What Exactly is a Systems Administrator?

A Quick NOTE: This document is a rewrite of a document done originally at a site known as "I2T". Many former readers of I2T have requested an abridged version - so here it is.

Disclaimer

This isn't a grip-line. I love my job - no doubt about it. I thoroughly enjoy working with UN*X Operating Systems, Devices and hardware (the most dangerous thing one can see where I work is me running around with a bucket of hardware, screwdrivers and a UN*X distribution CDROM). Many people who are not systems administrators, however, do not really have any conception of what they do, hopefully this will educate them a little without getting too technical, and perhaps enlighten folks who would like to move into the field of UN*X Administration and Engineering.

The Simple Preconception

The "definition" of a Systems Administrator is for most, that person who buys hardware, manages accounts and complains about disk space abuse. Well - no - those are part of being a Systems Administrator but aside from the rudimentary tasks there is a great deal more to it.

Here is a very abbreviated version of what most people think encompasses the job of a System's Administrator:

Believe me, there are probably a few I missed but that is a very generalized version of what the basic job description is.

Now let's move forward to reality.

Network Systems

Invariably a UN*X Sysadmin must at least get involved at some level with networking, as such, they must have a rudimentary understanding of basic network protocols and wire technology. While many Sysadmin books of yore (like 10 years ago) would put out a line like:

Then contact your network administrator to setup networking information

More recent publications awoke to the fact that no Sysadmin in their right mind will allow anyone else to configure their systems.

Power Scripter

You have to know how to shell program to be a UN*X administrator. Perl helps even more. Going a step beyond, the next section looks at programming in general that administrators may need to know for survival. Scripting comes into play for routine tasks, frequent checks, automating performance reports etc. It is also helpful when a user just cannot seem to remember a set of commands.

Basic Programming Skills are Required

I am a Senior Administrator, well, I am also the Lead and Head Administrator, oh, well then again, I am the only administrator where I work. I am Senior because I have been doing it more than 5 years, but Lead and Head because, well there is no one else here to do it! This is actually more often the case than not. As such, I have to have at least a functional level (or block level) understanding of C, Perl and C++. The reason is simple, there are times an administrator will have to look at source code for a ported application, a ported app's Makefile or - the worst case - some knuckle-head's code that you got stuck with or you know is not written well but have to be able to prove it. In the least, a Senior or Lead Administrator needs to have intermediate programming skills. Most of the time this isn't a problem as many administrators also program.

Coordination Skills are a Must

Another often overlooked factor about administrator's is that they must be able to coordinate projects, coordinate with development projects (predicating getting your server slammed by a new JAVA powered database) and coordinating certain user efforts (like a new production method for example). It is rare, if ever, that I see "basic communications skills required" on a job dexcription; yet administrators are often dragged in against their will (me being one of them) on projects they find totally uninteresting but may impact system operations.

Thick Skin

I make no bones about it, there at least 3 people, probably more like a couple thousand, who want to rip my heart out with a spoon, gouge my eyes out with a toothpick and pour salt and vinegar in all of my open wounds. It goes with the territory. People hate Systems Administrators for several thousand different reasons, the most prominent being we sure make it all look easy. As such many managers who are not directly connected to administrators tend to take on the same view (I have been fortunate not to ever have been in a chain of command that was like that - but unfortunately I have been lucky - so far).

Server Process Administrator

This is perhaps the most often overlooked function of a Systems Administrator by the uninformed. There are usually a variety of client and server systems the administrator has to keep an eye on, maintain, tune and manage just like the Core Operating System itself. Let's list a few then discuss the ramifications of this list:

Now, let's say you work at an organization where users access all of those services. Well - that is a lot of work. It is often taken for granted that we "just know everything" about all of these services, but that is not true. They all involve their own unique managment processes that we may or may not be familar with at any given time. A case in point, for the longest time I used (and still do) NFS. I fooled around with SMB for awhile then - well - dropped it. Awhile later, I had to revisit SMB and it was difficult because I left shifted all of that data out of my brain. Luckily I still had all of documentation bookmarked.

The Rest

Piled on top of all of that is the catch 22 stuff like going to conferences, following trade publications, searching the Internet for information via the web, gopher, archie, news and whatever else you can think of, it is a big job. So if you are not an administrator - remember - when an administrator looks at you and they are tired, exhausted looking or just plain pissed off - chances are - there is much more going on than you know.

By the same token, if they are smiling and laughing - be afraid, be very afraid . . .


(C) Copyright 1999, 2000 OutRider
See OutRider Policies Document for more Information.
Modified on $Date: 1999/10/01 12:56:14 $ by Jason Fink ( jrf@diverge.org )