When the topic for this month’s T-SQL Tuesday was announced here, it really got the wheels turning in my mind. So, in the spirit of this month’s topic, here is my spin on the official topic: “In the 10+ years I have been a database professional, we’re still dealing with a lack of communication between DBAs and developers as well as DBAs and operations staff”. In other words, can’t we all just get along?
Let us go ahead and separate this into two sub-topics: DBAs not talking to developers (and vice-versa) as well as DBAs not talking to operations staff (and vice-versa). While the consequences of each communication gap may be different, in my mind the solution is the same in both cases.
First, both when I was an operations DBA and now that I am a data platform consultant, I would consistently talk to DBAs who say “I don’t need to understand the applications running on my server(s), I just need to keep the lights on.” While that may technically be true by your job description, that will cause two problems, one for that type of DBA and one for the team with which they’re interacting. The problem for the team is that any performance and/or design guidance the team requests from that DBA will be, at best, misguided or, at worst, destructive. Blindly offering generic database advise or approving index or code changes from the team without the DBA(s) having a thorough understanding of the impacts truly does a disservice to the team being supported and will likely eventually lead to the team turning to Google/Bing for “expert” advice rather than their internal DBA staff. The problem for the DBA can be much more significant – if all you’re doing is keeping the lights on you are A) replaceable as you do not have much specialized knowledge and B) replaceable because your job may be automated or outsourced.
Second, I still talk to some database professionals who proudly declare their agnosticism regarding the servers their databases reside on, the network rails their data rides, and the storage their data uses. While I understand this decision, especially given the always-increasing amount of things “SQL Server people” are supposed to know, my experience in a lot of middle of the night phone calls over the years is that “I don’t know” is not a popular answer when it’s 3 AM, there’s something wrong with “the database”, and the company’s creeping ever closer to violating an SLA if the issue isn’t resolved ASAP.
I do understand our frustration, as a data professional, when a non-technical person accuses “the database” of being broken when what’s actually down is the SAN, the network, the battery backup on the UPS during a power outage, etc. That said, this is where having some basic knowledge of the system you support can go a long ways. If your answer to the manager called into the fire alarm call and demanding a response is “I don’t know” that will not reflect well on you. If your answer is “there doesn’t appear to be a SQL Server issue but let’s look at <storage, network, etc.> because I see X in my monitoring tools” that will not only bring about a faster resolution of the issue, most likely, but it will show those up the chain from you that you are a professional who thoroughly understands the environment you’re supporting.
The solution to all these issues is simply this: communicate. In a very real sense, the developers, the DBAs, and the network/storage/operations folks are all in this together because if the application you’re coding/refining/supporting runs into significant issues it can put everybody’s career at risk. Even if management doesn’t realize this and doesn’t facilitate the communication, make it happen for yourself and your colleagues. Break bread with them, have a beer, setup inter-departmental lunch and learns, or just ask them what’s new in their field or if they got any shiny new toys at work. I’ve done all of these things and seen them all work. Even if all else fails, maybe try this after receiving appropriate responses from all parties:
Feel free to contact me on Twitter with any follow-up questions or comments. Thanks for reading!