Change control

This Friday I will be addressing our internal team on the importance of change control and change management processes. I have been singled out due to my recent 'experiences' in this area.

This is especially critical on systems such as Microsoft's Small Business server product. SBS is a complex entwinement of a number of Microsoft technologies (a number of which MS recommend are not placed on the same server). Even the simplest change can cause untold late nights for the responsible individual.

Form an engineers perspective, I always feel the pull to getting my hands dirty, instead of following proper process. However, this somewhat casual approach is not without it's consequences.

Formal change control processes can become unwieldy, and by their very complexity discourage use. However, a simple framework can provide a invaluable 'sanity check'. My bullet points:

Make sure it's not broken first.

Does it work properly in the first place? Patching a server is a brilliant example of this. Take for example, an SBS server with a lingering port issue, such as that introduced in ms08-037

Do you have a backup?

Do you, really? And is it any good. Any change, no matter how basic, always has the potential to go rouge. Sometimes you will need to roll back, and you need to be confident that you can. I am fortunate enough to have access to Shadow Protect for taking point in time backups prior to undertaking any work.

Have you thought about this?

What (or who) could be effected?

Is there a plan B?

Are you sure?