A few weeks ago Grant Fritchey (b|t) posted about DevOps, the DBA , and the word “No”. Go ahead and read it, I’ll wait right here.

Welcome back. As you’ve just read, Grant ranted a little on the concept that the DBA does nothing but say no to requests, and that people still live the belief that it’s their default response to anything.

The whole concept of the DBA saying no really comes about because the people that are responsible for getting up in the middle of the night, because somebody did something crazy that broke the site, are not fans of a lack of sleep. Hey, if you knew that there was a not-null probability of losing an evening, or a weekend, wouldn’t you be hesitant to allow changes as well.

I spent many years as that gatekeeper. The one that didn’t want to lose that time. I didn’t want to spend my time saying no, but I knew for darn sure that I wanted to understand what was going in and what the potential impact was going to be. After all, I’d rather spend my time figuring out how to simplify managing my enterprise than trying to figure out what was broken with the latest release.

A few months ago I made a bit of a swerve and moved into the realm of the DevOps DBA. Now I straddle the fence and have feet in both the dev and the ops world. One of the most interesting things about this simple change is how my appreciation has changed for what the developers are going through.

Getting stuck in stand-ups, listening to program managers push things, and trying to fit work into various sprints and manage a virtual kanban board is a little bit eye opening.

“No” vs “Why?”

It’s a very small word change, but a serious mind shift.

Sometimes a dev just has to do what’s needed in order to get things through.  That does not mean that they can get away with terrible coding, or with doing really bad things, but what it does mean is that rather than go back and say “you can’t do this, here’s why, please fix”, it’s “I see what you’re doing here, can you help me understand why you are doing it so that we can see if we can find a better way to do this, that will fit in the time frame for the release that this needs to fit in?”

Better yet, thanks to the DevOps type role I get to see what code is being checked in to the source code repository. Most devs will actually include me on SQL commits, prior to their being merged to the main branch, so that they can get early feedback, and not get their changes scuppered later on during a regular code review. In addition, with multiple test environments, and continuous integration, alongside full backwards compatibility testing, we can catch, and if needed revert or resolve, nearly all SQL problems well before they ever get to production.

You’d think that after more years than I care to remember as a DBA, I wouldn’t be going soft on people, but devs are people too (well most of them anyway).

A challenge

I don’t know whether your shop supports the opportunity, but if it does, try spending a few weeks in the DevOps realm. It might just give you an entirely new outlook on things.

P.S. that goes for you devs out there too. You’d learn a lot by having to put out those metaphorical fires for a bit.