August 23, 2012 by Mike Hillwig
Similar to manual processes, if I have to answer a question more than twice, I’m going to document it. It allows me to give people what they need, using time more efficiently because they can read it at a time that works for just themselves, instead of waiting until we’re both available. It’s also a means of giving my staff on the other side of the planet something to reference instead of calling me.
A few weeks ago, we had a situation where one of our Oracle DBAs decided he was going to build a SQL Server. Because I’m deploying servers rather frequently, I have the process down to a science. I know exactly what to request from my storage team and exactly how to phrase things with my Windows team so that the server comes to me ready to go. There are typically no questions and the process works like a well-oiled machine.
This guy didn’t do that. The process was an absolute mess. And I realized that this was my own fault. Yes, I had the process documented but it wasn’t published. If the standard isn’t published, how can people be expected to follow it?
Because it caused such an issue, I ended up having a meeting with all of the players involved, and we’ve actually put together formal standards for our SQL Server builds, including having a small inventory of servers ready to be used for new database instances as needed. All we need to do is provision the storage and install the instance.
But now, everything is documented. And the first item on our build standards documentation is that every new instance needs to be reviewed with the DBA Manager (my boss) prior to submitting requests for anything. That means we’re not caught off guard. And that makes me a little less cranky.