| Red Hat Linux 8.0: The Official Red Hat Linux System Administration Primer | ||
|---|---|---|
| Prev | Chapter 1. The Philosophy of System Administration | Next |
If given the choice between installing a brand-new server and writing a procedural document on performing system backups, the average system administrator would install the new server every time. While this is not at all unusual, the fact is that you must document what you do. Many system administrators will put off doing the necessary documentation for a variety of reasons:
Unfortunately, this is usually not true. Even if a system administrator is not kidding themselves, the nature of the job is such that things are usually too chaotic to simply "do it later". Even worse, the longer it is put off, the more that is forgotten, leading to a much less detailed (and therefore, less useful) document.
Unless you are one of those rare individuals with a photographic memory, no, you will not remember it. Or worse, you will remember only half of it, not realizing that you are missing the full story. This leads to wasted time either trying to relearn what you had forgotten, or fixing what you had broken due to not knowing the whole story.
While this may work for a while, invariably it leads to less — not more — job security. Think for a moment about what may happen during an emergency. You may not be available; your documentation may save the day by letting someone else fix it. And never forget that emergencies tend to be times when upper management pays close attention. In such cases, it is better to have your documentation be part of the solution than for your unavailability to be part of the problem.
In addition, if you are part of a small but growing organization, eventually there will be a need for another system administrator. How will this person learn to back you up if everything is in your head? Worst yet, not documenting may make you so indispensable that you might not be able to advance your career. You could end up working for the very person that was hired to assist you.
Hopefully you are now sold on the benefits of system documentation. That brings us to the next question: What should you document? Here is a partial list:
Policies are written to formalize and clarify the relationship you have with your user community. They make it clear to your users how their requests for resources and/or assistance will be handled. The nature, style, and method of disseminating policies to your user community will vary from organization to organization.
Procedures are any step-by-step sequence of actions that must be taken to accomplish a certain task. Procedures to be documented can include backup procedures, user account management procedures, problem reporting procedures, and so on. Like automation, if a procedure is followed more than once, it is a good idea to document it.
A large part of a system administrator's career revolves around making changes — configuring systems for maximum performance, tweaking scripts, modifying printcap files, etc. All of these changes should be documented in some fashion. Otherwise, you could find yourself being completely confused about a change you made several months before.
Some organizations use more complex methods for keeping track of changes, but in most cases a simple revision history at the start of the file being changed is all that is necessary. At a minimum, each entry in the revision history should contain:
The name or initials of the person making the change
The date the change was made
The reason the change was made
This results in concise, yet useful entries:
ECB, 12-June-2002 — Updated entry for new Accounting printer (to
support the replacement printer's ability to print duplex) |