Chapter 1. The Philosophy of System Administration

3

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)

1.3. Communicate as Much as Possible

When it comes to your users, you can never communicate too much. Be aware that small system

changes you might think are practically unnoticeable could very well completely confuse the admin 

istrative assistant in Human Resources.

The method by which you communicate with your users will vary according to your organization.

Some organizations use email; others, an internal website. Still others may rely on Usenet news or

IRC. A sheet of paper tacked to a bulletin board in the breakroom may even suffice at some places. In

any case, use whatever method(s) that work well at your organization.

In general, it is best to follow this somewhat paraphrased approach used in writing newspaper stories:

1. Tell your users what you are going to do

2. Tell your users what you are doing

3. Tell your users what you have done

Let us look at these three steps in more depth.

1.3.1. Tell Your Users What You Are Going to Do

Make sure you give your users sufficient warning before you do anything. The actual amount of

warning will vary according to the type of change (upgrading an operating system demands more lead

time than changing the default color of the system login screen), as well as the nature of your user

community (more technically adept users may be able to handle changes more readily than users with

minimal technical skills).

At a minimum, you should describe:

The nature of the change

When it will take place

Why it is happening

Approximately how long it should take

The impact (if any) that the users can expect due to the change

Contact information should they have any questions or concerns

Here is a hypothetical situation. The Finance department has been experiencing problems with their

database server being very slow at times. You are going to bring the server down, upgrade the CPU