Are you controlling access to your server room? Are you documenting that access, too? You should be.

In last week’s column, I discussed designing a server room within your financial and physical means. In that article, I touched on the idea of change control. Like the server room itself, this “formality” of a written or database record can be applied in any size organization or installation.

When you implement this discipline for the first time or come to review its place in your procedure manual, you should remember that its benefits should be reaped from the process of acting out change control and from the resulting history of changes it provides.

So, what is change control?
Literally, change control should “control change” by providing a mechanism for realizing the following opportunities:

  • Reasoning out changes before implementing them—and documenting the reasons for the changes
  • Providing an authority for executing the change
  • Providing accountability through a recording of changes
  • Providing enough information to make an informed reversal of the change possible

This all may read as though some very stringent and triple-copied paperwork is required. In large organizations, where a single change is to be replicated across a farm of application servers, e-mail organizations, or other mission critical systems, this may be true. You should, however, be able to balance the discipline against your organization’s structure and culture.

At the simplest end, where a single administrator is the system engineer, IT manager, and authority, a short entry in a simple logbook may suffice. This entry should describe the reason for the change (maybe a driver update), the version of the fix being applied or the options being changed, the date and time of the change, and a signature.

Further up the scale, a proposed change may be supplemented on a specific form with detailed installation instructions or change procedure, a separate authority signature, an indication of whether backup procedures are still valid, and specifications on whether a special backup should be taken before the change.

Even stronger measures may require a supporting document on the reason for the change, lab test results, back-out procedures, and authority from third-party support agents.

In all cases, it is also a good idea to sign off the change as complete—after the change has been tested in the live environment. When you are satisfied that all is well, move on to the next change.

It’s not a noose!
The purpose of accountability is not to provide the rope to hang someone on, although it is often seen that way. The long and short of it is this: When faced with a sick server late in the evening, you have a better chance of fixing it if you know what recent changes have been made to it.

If you’re an IT Manager, insist that your team adhere to change control measures. If you’re “the” administrator, ensure that you stick to them. If you’re a support member, instill the importance of tracking changes among your clients and staff.

David Parkinson lives and works out of the green and pleasant land of the Ribble Valley in the North West of the UK; loves football, MS NetMeeting, and reading contemporary fiction. He wishes he could travel more but knows he can’t have everything. You can e-mail him at David.parkinson@ctrl-key.co.uk.

If you’d like to share your opinion, please post a comment below or send the editor an e-mail.