A Wandering Mind

Well, almost. As of this coming Monday at least.

That’s right kids. Starting next week, I’ll be moving into a (gasp) Development centered role, acting as the database guru for a bunch of internal development teams.

What’s this mean in a nutshell? Well, among other things…

No More Pager

Yes, I know, as Tom LaRock (blog | twitter) very aptly puts in his book DBA Survivor, “A Development Server is A Production Server To A Developer.” But, at least for now, that only extends within business hours. No more wakeup calls at 3AM to deal with slow-moving servers.

Lots More Code Reviews

Up until now, code review was an activity that was handled by the production DBA team, including myself. And while I think all of us agreed it was a vital role to have, we were never really able to give it the kind of attention it needed. After all, as production DBAs, our main focus had to be on keeping production systems up and running.

“But Josh, doesn’t reviewing code help keep production systems running smoothly by preventing bad code from getting there in the first place?”

Right you are, and that’s why a dedicated part of my new job will be performing code reviews and ensuring everything follows standards. I’d be lying if I said I’m thrilled about the prospect of filtering through all those lines of code, but I do understand its importance and I’m honored to be given that responsibility.

It’s Cleanup Time

Another part of my role is taking ownership of a good number of Development owned database servers. This process includes auditing for configuration and setup, patch level, security (can you say “Powershell” people?), and planning for remediation to bring the servers into compliance with how our production systems are setup.

This to me is just as important as reviewing code in terms of helping our teams (both Development and Production) to have success in releasing code. Think about it: if you are running all your tests under a highly privileged account, on a server which is left wide open in terms of permissions, you could have a rock-solid test-case plan and still run into major issues when you try and move into a live system. While I’m sure that I’ll encounter some resistance (“What do you mean we can’t have the ‘sa’ password any more?!”), I’m confident that in the long run everyone will benefit from this inoculation of best practice methodology. Plus, the development teams can rest easy, knowing that their servers are being backed up and DBCC’d regularly, as opposed to hoping months of work doesn’t just go down the tubes courtesy of our friend Mr. Corruption.

Overall, I’m truly excited about the change. I will miss the adrenaline of dealing with production issues and the constant problem solving. But at the same time, I’m looking forward to attacking the kinds of problems we encounter as DBAs from a proactive approach, and building, dare I say, a strong rapport with our friends who pound out code on a daily basis.

On a closing note, I’d be remiss if I didn’t thank the members of my team for the wonderful ride over the last 6 months as a production DBA (has it really only been that long?). You’ve been (and will continue to be, since I’m still going to be working with you) exceptional teammates and I can’t wait to continue contributing to our team, just from a different angle.

Be Sociable, Share!

•