There are two kinds of sysadmins:

Those who say, "The system is there to support the users in furthering the purpose"

And those who say, "The system is beautiful and perfect and fast, until all those lousy users log on."

Be sure your sysadmin is the former type.

A system administrator, or sysadmin, is (broadly) a person employed to manage one or more computer systems. The term is a catch-all for many different kinds of jobs. Especially in a small organization, a sysadmin is likely to serve as a jack-of-all-trades for computer-related matters.

Generally, a sysadmin works with mainframe or server computers, rather than desktop and workstation systems. In many modern shops, "sysadmin" equates to a maintainer of Unix systems in particular; this may be because NT and NetWare sysadmins seem to prefer to hijack the term "engineer" for themselves.

A sysadmin is often the chief in-house technical authority on his or her systems, though s/he is not usually a ranking organizational authority (such as a manager). He or she is probably responsible for troubleshooting and upkeep on these systems, as well as resource management, user management, and some manner of policy enforcement. If the system crashes or in other ways fails, it is the sysadmin's job to bring it back to a usable state.

S/he may do the backups and other routine tasks, or may hand this off to an operator or other underling.

S/he had damn well better be thinking about security as well.


One of the myths of computing is that sysadmins are as a rule hostile, disgruntled, or hazardous to your health. This myth is furthered by the hilarious "BOFH" saga by Simon Travaglia et al., now continuing in The Register. Yet while many sysadmins find the BOFH's exploits -- and his gleeful incineration of lusers -- wildly entertaining, few will actually kill you for asking dumb questions.

Understand, though, that sysadmins (like everyone else) get frustrated when folks keep them from getting work done. In general it is the sysadmin's job to make the servers function properly. S/he is not helpdesk or desktop support, and likely is not being paid to remove cheese from your floppy drive. Neither is it the sysadmin's job to throw security, good practice, and the good of the organization aside in order to grant you more network access, system privileges, or quota for your MP3s.

It is those sorts of things -- along with dodgy hardware, buggy software, tight budgets, spam, and miscellaneous cluelessness -- which increase your sysadmin's blood pressure and cause him or her to cackle all the louder at the BOFH.

sys-frog = S = sysape

sysadmin /sis'ad-min/ n.

Common contraction of `system admin'; see admin.

--The Jargon File version 4.3.1, ed. ESR, autonoded by rescdsk.

When you're in High School, learning the ropes of Linux or OS/400 or whatever else, IT seems like it would be a pretty relaxing career. Sitting in a comfy office with terminals connected to powerful and largely self-sufficient machines in a nice, cool, datacenter, responding at your leisure to respectful requests for features from users... what's not to like? Sadly, the truth isn't like that. It isn't even close.

There are three big IT Scenarios that will result in hell for you, the chipper young IT girl: the Upgrade, the New Installation, and the Awful Legacy System. The Upgrade and the New Installation are closely related, while the more distinct Awful Legacy System can occasionally make the Upgrade necessary or even a good thing. Sooner or later, every installation of any size - even ones with a few dozen users - will go through one, two, or even all three of these situations.

If you're really unlucky, or maybe just desperate for work, you'll find yourself in the middle of the New Installation. If you get off easy, your employer wants something simple that can be handled by LAMP, or perhaps Windows Server and Active Directory, with minimal customization and commodity hardware. Ultimately, of course, this will probably evolve into an Awful Legacy System, but in the mean time, your job is easy and the system can hopefully be set up and tested in a few days. If your employer has higher requirements for reliability or performance, it's your lucky day: you get the rare and lovely opportunity to talk to one of the three Big UNIX Vendors, Oracle, HP, and IBM.

What a lot of armchair sysadmins on forums miss is that technologically, for most applications, these guys are roughly interchangeable. Yes, Power7 is faster than Itanium, and Itanium is faster than SPARC, but the extent that it matters in the real world is relatively minimal. Most of the tradeoffs here are financial. For instance, IBM licenses software per core, rather than per socket like HP; that means that in the money saved from licensing by going HP, you could potentially get a 64-socket Superdome (HP's high-end) instead of a 32-socket 795 (IBM's high-end). You can also ignore the list prices these companies have posted, since they exist almost purely so that the sales rep can give you 80% off of the list price and talk about what a great discount he's getting you. Ignore anything you find on the Internet, and instead ask each sales rep these questions.

  • How much will the system cost, from start to finish, to acquire? Include software, hardware, and services. Do not let the rep bullshit you.
  • What are the industry-standard benchmark results for the type of application you wish to run on the system? If you're running an enterprise Java application, demand SPARCjbb. If it's a database server, tell the vendor you want a TPC-C or TPC-H result for the type of system they're trying to sell you. If it's technical computing, check SPECcpu2006. Do not allow the vendor to try to present some kind of proprietary benchmark - both IBM and Oracle are notorious for this.
  • Ask to see a roadmap for at least the next five years. Look over it very carefully, since on UNIX systems vendor lock-in is a huge factor.

After you've done this, figure out a quick price/performance estimate for each, and calculate how much having each system on a service contract for the next five years will cost. Go with the cheapest.

The Upgrade is the least fun, especially since it can bring along its friend, the Migration To Another Platform, if you weren't careful enough during the New Installation or if the vendor did something unpredictable. The Upgrade involves a lot of the same things as the New Installation, except you have an application that needs to be ported, and user data, and users that will get very, very upset if there's any downtime. You'll soon find that C is not really a portable language, and that even Java has its own bizarre porting difficulties. Auxiliary stuff - libraries, database components, native routines - will need to be ported, and frequently this is not easy. If you're sticking to the same platform, but a newer box, you can sometimes do an automated migration (HP-UX is exceptionally good at this), but most of the time you won't be so lucky. Even once you're congratulating yourself on getting your PA-RISC/HP-UX application running on SPARC/Solaris, it's not really time to celebrate; in five minutes a user will call and start complaining about how it's running painfully slow, much more so than before, which shouldn't even be possible. Then you get to dig through logs and source code, figure out why, and fix it.

Sometimes, you'll be job-hunting. You'll see a promising post - maybe it will say "Active Directory admin for small network needed," or perhaps "Looking for a laid-back HP-UX guru." Horrors lurk within such things. The interview will go well, you'll sit in your new office, and a higher-up will casually mention that there are no Group Policy Objects and all users are managed with scripts in their Startup folder. The scripts are esoteric and the guy who actually knows how they work left a year earlier. The sinking feeling in your stomach confirms it - you have entered the land of the Awful Legacy System! Meanwhile, users will be sending emails demanding that you pick up their computers (1.8GHz Pentium 4, 256MB RAM) and fix them because Vista is running slow. As you frantically try to get the Active Directory configuration into something resembling usable, calls will start coming in about how a legacy application you've never touched and never been told about isn't working right. "What's the error message?" you ask. "I don't remember," they answer. Things go nowhere good from here.

When I entered the workforce, I thought IT seemed like the coolest thing ever. I survived a year of it with a degree of sanity and without my love of computers burned out, and now I've found my true calling: software development. It taught me skills that I wouldn't trade for anything, but I am never, ever going back to anything resembling a sysadmin job.

Log in or registerto write something here or to contact authors.