I swear I have been thrown under the bus so many times recently it feels like I have tire tracks on my back. I know, I know to be in this business we have to have tuff skin and it usually doesn’t bother me. Recently though two projects have been the bane of my workload.
It’s Just Policy
I in a data center where we have policies, procedures and standards for creating, maintaining project environments from development all the way through to production. We, as production/operations DBAs do not do development. That is handled by the individual projects according to the contracts. The only code (T-SQL or PowerShell) we write is related to operational tasking. Like routine maintenance tasks to keep the databases operating in a 24/7/365 environment. We have heavy oversight as well, all work must be tracked by different levels of Change Order tickets.
Upper management realized we were constantly overloaded with deployments on top of our normal trouble shooting and performance tuning tasks. Within the last year we added a new part for deployments, a release calendar. Only a certain number of releases are scheduled during a given week. That allows us time to be able to review instructions and code and if discrepancies are found, time to correct them prior to the release date. Over all we have a less stressful work environment. For the most part J
In order for a project to release a new version of their application they must be on the calendar. Approving a calendar slot requires the code, instructions and all change orders be ready at a minimum of 72 hours prior to the release date. The project can release any time during that week. Preferably early on so when/if issues are encountered they can be corrected.
Back out Plan
A required part of all deployments is a back out plan. Anyone, DBA or SA can stop the deployment and engage the back out plan. We usually don’t have to engage the plan but I have been known to through a few wrinkles in some skirts from time to time.
What can constitute engaging the back out plan? The biggest problem/issue is SQL scripts failing. Now mind you depending on how easy the development team is to work with and the failure in the scipt I have been known to fix a thing or two to make the deployment successful. I do inform the developers what was wrong and what was fixed but don’t air the dirty laundry to the world.
On the other hand, if you are difficult to work with, continually make unfounded and false accusations of dropped tables, configuration changes to folders on the server, and then send an email naming me directly and others at the data center as not having the basic skills to be able to support the project. Then you better run a very, very tight ship. I won’t go out of my way to look for something wrong. I don’t usually have to. Teams people that do things like that usually have problems already and are just trying to push focus off their inadequacies, missed deadlines or other major problems meeting the requirements on the contract.
Where am I going with this? In life you should never, never make certain people angry with you. Former military people will attest to this. You don’t make enemies with Corpsman (they can lose your shot record), Yeoman (they can lose your pay records), and cooks (they can put strange ingredients in your food). That translates to the data center hosting your application, you don’t want to make enemies with your SAs or DBAs.
Don’t PO the DBA. Period end of story.