System administration

The job of making sure that computer systems are up and running. The work involved can be split up into tasks; some are one-time, some reoccur and often present the opportunity for partial or total automation, which is then a task in itself. The tasks are usually part of an ongoing project; projects involve one or more specific systems, of which one is usually the main subject. So tasks can usually be classified according to the kind of system they address and the phase of the project they deal with.

system type:

hardware

power supplies, motherboards, insertion cards, monitors, cables, racks, stacks of tapes, tables, doors, keys, cardboard boxes, screwdrivers, etc.

software

operating systems, specific system services, end-user applications, standard utilities, homegrown additional utilities, etc.

wetware

users, co-workers, management, vendors, intruders

project phase:

1. open-ended preliminary research
2. requirements analysis
3. product evaluation / construction
4. acquiring the product (if commercial)
5. installation
6. testing
7. local documentation, announcement, demo, negotiating agreements on support
8. regular maintenance on the running product
9. support to users / anyone else involved
10. renewing license / reinstalling elsewhere / upgrading
11. disabling / deinstallation / discontinuation of product

Not all of the project phases are required for every project, and sometimes they can be rudimentary. For example, if you are adding a simple script that nobody else will ever use, the documentation and announcement part will be fairly small; but when installing popular software with hundreds of users that will need to be maintained by colleagues, you have to do serious documentation and announcements both for the end users and for your colleagues.

If you limit a project to only the interesting phase (turning it into a quick hack), not having done the boring parts may turn against you later. Proper documentation, for instance, can really save you time on repeated tasks.

Similarly, if you limit you concern to dealing with only the interesting systems (the software, obviously), the uninteresting ones (mostly, hardware and people) may come back to haunt you: you should have replaced that cable; you should have spent a few hours trying to call that vendor; you should have addressed that user complaint; etc. etc.