Change management: what's the big deal?

You're used to making changes to your own computer system(s) all the time. If something doesn't work the way you want, you reconfigure it. You install or remove software more or less at whim. If something's not working, you are the only one who's affected, and you're also probably pretty aware of the history and specifics of your own computer to guide you in fixing it.

If system administration is about running computer systems for other people to use, then the issues of change mangement arise because your decisions to change things can have tremendous effects on those other people -- the people who use the system, and the other people you work with to manage those systems. A system that's being run for a number of other people is also usually much more complicated than a system you run for yourself, and the implications of changes are less obvious.

This leads to some basic principles of change management for system administration:

• Avoid change merely for the sake of change. When other people are depending on your services and have their own established procedures for getting things done, unnecessary changes cause disruption.
• Changes must be communicated. This at least means informing other sysadmins or staff so they all understand the state of the system. Changes that affect users need to be communicated to them, either because something changes how users interact with the system or because a change involves making the system unavailable temporarily.
• Changes must be documented. What was changed, why it was changed, and how it was changed? Consistent documentation provides a history of the system that can be used to understand its current state and how that state was reached. This also means that changes can be recreated if a system has to be recreated.
• Changes must be planned. In particular changes that have user-visible effects, such as changes in software behavior or system downtime, should be scheduled in advance, so that potential disruption can be minimized and users can get advance notice. This also means figuring out how to implement the change efficiently in an organized manner.
• Making a change should allow the possibility of unmaking it. Changes often have unintended consequences or don't do what they were intended to do. If the result of a change leaves you worse off than before, then you want to be able to get back to the prior state.

Next ->