Document Everything - Red Hat ENTERPRISE LINUX 3 - INTRODUCTION TO SYSTEM ADMINISTRATION Administration Manual

Introduction to system administration
Hide thumbs Also See for ENTERPRISE LINUX 3 - INTRODUCTION TO SYSTEM ADMINISTRATION:
Table of Contents

Advertisement

2

1.2. Document Everything

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 orga-
nization 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.
Chapter 1. The Philosophy of System Administration

Advertisement

Table of Contents
loading

Table of Contents