Communicate As Much As Possible; Tell Your Users What You Are Going To Do - Red Hat ENTERPRISE LINUX 4 - INTRODUCTION TO SYSTEM ADMINISTRATION Administration Manual

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

Advertisement

Chapter 1. The Philosophy of System Administration
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 can 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 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
The following sections look at these 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 necessary varies 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
3

Advertisement

Table of Contents
loading

Table of Contents