September 28, 2009 by Mike Hillwig
I’ve said before that I’m a nut for consistency. What I haven’t said yet is that I’m an even bigger nut for change management. The last two companies where I’ve worked have been small IT shops, and the lack of change management is absolutely maddening.
I have to say that a chunk of my career was spent in an IT shop that started as a mainframe shop. In fact, when I left in 2003, the mainframe still ran a big chunk of the mill. They had serious practices in place. And this is where I learned a lot of what I know about best practices for change management.
When I needed to change anything on one of my Exchange servers, I simply logged the change, my boss signed off on it, and then we moved on. It would be brought up at that day’s daily change/problem meeting. Usually it was a footnote on a report, but once in a while, the director wanted to know what the impact was or what the fallout might be. In most cases, we tried to log things before implementing them, but it wasn’t always practical.
At the utility company, I was working as a developer, and our change management requirements sometimes felt onerous, but in retrospect, they were brilliant. We had to provide a paragraph that indicated what the change would accomplish. Then we had to provide documentation that it was successful in testing. This usually required attaching before and after datasets. It seemed like a lot of work, but it worked for us.
Sometimes I really miss that structure. If I change an index on a table, I really should have a record of that change. Not only does stuff like this keep auditors happy, but it’s an amazing resource in troubleshooting.
If I get a problem with performance and the user states this problem started occurring last Friday morning, my first instinct is to check what changed. Most systems don’t just break. Problems are typically caused by unintended consequences of changes me make. In this case, I’d start looking for any changes I made Thursday night or Friday morning. When you have a system that tracks this for you, it can really work for you.
As DBAs, we tend to look down on more regulations to changing systems, but this is one I will certainly advocate. Changes shouldn’t be made on the fly. Instead, they should be done in a controlled manner, and they should be well documented.
Category SQLServerPedia Syndication | Tags: