September 5, 2001 at 2:53 pm
I was just wondering how other companies handle the DBA Roles. We have 2 DBA Teams, a Development DBA Team, and a Networking DBA Team.
The Development DBA team creates tables, stored procedures, jobs and DTS Packages.
The Networking DBA Team maintains permissions, does backups and creates database shells.
The current managers do not trust the Development DBA Team out of the development SQL Server, so our 'sa' rights have been revoked. The current procedure is to ask the networking DBAs for permission to be granted to you for the production SQL Server, and then you make the changes.
The procedure that is going to be that we have a NT Account that only the Networking DBA's and the Development DBA Team Lead has the password for. When a change needs to be made to production, we will walk over to a specific PC (Currently in the Development DBA Team Lead's cube) and sign in on a piece of paper, and have the Team Lead watch us, after he has approved what we are going to do. Then we will sign out.
I think both processes are ludicrous. I was just wondering how other companies handle issues such at these, or if they are really issues.
Thanks!
September 5, 2001 at 4:04 pm
In my previous job no dev dba touched a production box once it was in production. If there were changes to be made they were done in test/dev then scripted out. I would look the scripts over test them on a roll server then if everything went right I rolled it into production during one of the nightly or weekly windows. I don't think it is crazy at all. I've been a Dev dba and I am a production dba now. After having several sleepless nights when a dev dba rolled something out and broke production I can see why your prod team is so protective. Once I rolled out the new rules production stablized and we had a total record of what was done via scripts so if anything did go wrong we knew where it happened. We got a better dev team out of it, they didn't roll stuff out willy nilly, and we got a better production env out of it. I did hear some of the other non-ms-sql dba's complain about the policy because of the "overhead" in work load, but once they stopped getting panic calls during the day and night they saw it was worth it too.
So, to sum up, yes you need tight control over production. Is it a pain the ass, yes.
Ask around, I bet you find someone in your org remembers when the procedure wasn't the case and a database was killed.
Just my .02$ worth.
September 6, 2001 at 10:46 am
I am split here.
I think change control is critical and dev people (DBAs, programmers, etc) should not change production. I know someone has to wear both hats (I know I do here), but you have to separate them. NOTHING should happen to production without having moved out of development and into a QA environment. Once it is tested here (no dev people in QA either), then you can move it to production (from QA).
Personally, looking at your description, I wouldn't allow the dev DBA to make the change. It would have to be scripted and the script tested. The script would then be ru by the network DBA.
For Dev, however, I think dev people should have rights so they can test and change objects as needed. If you micromanage dev, it will become extremely tedious. When a dev person makes a change, then changes it back, then changes it again, the person monitoring will get upset, but that is part of what is needed in a development cycle.
Steve Jones
September 14, 2001 at 3:34 pm
Our production DBA's manage the movement of most projects from Development (DEV), Test (TST), and Production (PRD). Smaller, simpler projects test in DEV. Critical and larger projects have extensive QA applied. Our production DBA's spend most of their time on DEV boxes. Prodocution tends to run fairly smoothly once you get past the initial implementation or upgrade period.
Our DEV DBA's tend to be sandboxed by funding and thereby focus on just a project or two. A couple of the DEV DBA's have rights in TST and PRD for trouble shooting purposes. However, DEV DBA's normally coordinate any change control with the production DBA's for any activity outside of DEV.
When speaking in broad terms it is important to maintain perspective concerning the size and criticality of an application.
A variety of technical and funding scenarios means we have some apps that are on dedicated hardware and other apps that are on shared systems. Generally if a customer funds their own hardware they have a legit business case for more access. We don't give them all the keys, but often do provide more access than they would get on a shared system.
September 24, 2001 at 7:46 am
It sounds like everyone works at large companies, so perhaps what I say won't mean much.
At my previous job I was one of two DBA's. The only machine we had was our production one. There was no developmnet nor testing environment. As I look back I wonder how we got along.
I now work for bigdough.com. We have a development and testing environment. However, our database team only has three people. My title is SQL Programmer. My supervisor is the official DBA. He mostly supervises and has me report to him major changes. I and the other SQL Programmer do most of the SQL developing along with some VB and CF programmers. We (the two SQL Programmers) move everything from development to testing and we do most of the testing, aided by the programmers (CF or VB) that developed stored procedures for their applications. Usually, I move everthing to production once enough testing has been done. But, everyone in the database team can move anything to production as needed. My supervisor and myself are on call for any interuptions in our production environment.
I think I would get frustrated if I didn't have access to the production environment and had to pass everything on to my supervisor for him to implement. But, then I've yet to work as part of a large database team.
Robert W. Marda
Billing and OSS Specialist - SQL Programmer
MCL Systems
September 24, 2001 at 9:57 am
I'm the only SQL Server DBA, but I don't have the startup/domain admin password, so I can't to upgrades or installs. The network backup person does the backups to tape/CD; the help desk maintains users, but I do permissions at a table level. The developers can migrate stuff to test and qa using the version control system, but I still do all of the production migrations. I don't like being a bottleneck and grant the on-call developer job ownership on production jobs.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply