|
|
 |
|
| |
NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
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, you must document what you do. Many system
administrators put off doing the necessary documentation for a
variety of reasons:
- "I will get around to it later."
-
Unfortunately, this is usually not true. Even if a system
administrator is not kidding themselves, the nature of the job is
such that everyday tasks are usually too chaotic to "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.
- "Why write it up? I will remember it."
-
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 whole
story. This leads to wasted time either trying to relearn what you
had forgotten or fixing what you had broken due to your incomplete
understanding of the situation.
- "If I keep it in my head, they will not fire me — I will
have job security!"
-
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 resolve the
problem in your absence. 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 it is for your absence 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 can 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
-
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 are handled. The
nature, style, and method of disseminating policies to your a
community varies from organization to organization.
- Procedures
-
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.
- Changes
-
A large part of a system administrator's career revolves around
making changes — configuring systems for maximum performance,
tweaking scripts, modifying configuration files, and so on. 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 earlier.
Some organizations use more complex methods for keeping track of
changes, but in many 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)
|
|
|
