DBA: Mentor vs. Protector

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQLServerCentral.com » Editorials » DBA: Mentor vs. Protector

45 posts, Page 1 of 5

1 2 3 4 5 »»»

DBA: Mentor vs. Protector

Rate Topic

Display Mode

Topic Options

Author

Message

Matt Simmons

Posted Monday, August 17, 2009 9:38 PM

Old Hand

Group: General Forum Members
Last Login: Tuesday, June 05, 2012 6:32 PM
Points: 341, Visits: 131

Comments posted to this topic are about the item DBA: Mentor vs. Protector

Matt,
Peace Out!

Post #772414

Elliott Whitlow

Posted Monday, August 17, 2009 10:20 PM

SSCertifiable

Group: General Forum Members
Last Login: Today @ 10:09 AM
Points: 5,863, Visits: 4,886

In the dev environment I would say mentoring is important with an eye towards security. In the production environment data protector is the most important..

CEWII

Post #772420

peter.town

Posted Monday, August 17, 2009 11:06 PM

Forum Newbie

Group: General Forum Members
Last Login: Sunday, December 18, 2011 1:06 PM
Points: 7, Visits: 6

Certainly in the production environment, the buck stops with the DBA for any bad structures. Because of this the DBA must be protector on the Production, QA and Test environments.
IMHO the average programmer does not understand database performance issues especially in the case of large databases making them dangerous if left unchecked. I favour the programmer having his own database to code against etc, but there sghould also be a common pre-test build environment and corresponding database. Any database scripts should be under code control just like programs. In this context, the DBA is the programmer.

Sorry Matt, but in my experience ex Access programmers are the most dangerous when it comes to [not] understanding the performance issues arising from 100+GB OLTP databases.

Post #772425

majorbloodnock

Posted Tuesday, August 18, 2009 1:18 AM

Ten Centuries

Group: General Forum Members
Last Login: Tuesday, June 04, 2013 10:52 AM
Points: 1,043, Visits: 2,945

To learn, one has to try something new. To try something new means risking failure. If you're not making a few mistakes, you're not trying to learn. In my opinion, one of the best ways to help someone onward is to give them just a little more responsibility than they can handle.

Now, mistakes cannot realistically be tolerated in a production environment, hence the need for the dev, test, pre-prod and sandpit environments. However, what's the use in creating somewhere for developers to develop (together with the bugs they'll encounter along the way) and then locking it down so tight as to all but stifle the development?

As we've discussed on previous threads, I believe security is only in part a technical issue, the greater part being the human dimension. If the DBAs and developers in a team work at their relationship rather than relying on technical safeguards and barriers, the understanding that grows between them can be reflected in wider (monitored) freedom within the volatile development environments. And, because this scenario involves DBA and developer working together, any code that has to be promoted to live has already become familiar to everyone involved.

Yes, I believe there's a happy medium, but I don't believe it to be a compromise. Rather, I believe it to be the best of both worlds.

Semper in excretia, sumus solum profundum variat

Post #772453

Silverfox

Posted Tuesday, August 18, 2009 1:37 AM

SSCrazy

Group: General Forum Members
Last Login: Tuesday, March 26, 2013 6:50 AM
Points: 2,719, Visits: 1,065

Depends on the organisation, The production environments have always had been the DBA pregorative and closely guarded, being a developer as well as a dba for a number of years i can see both sides of the argument. The trouble is, is that not all developers are alike or even have the same skills/knowledge/attitude.

Some of the organisations I have worked for in the past, the dev boxes have literally been given over to the developers who have done what they want to them, having full sysadmin rights. I have mentored in the past, junior dbas and developers who wanted to learn. But never within any other environment then development. With all the best intentions, a production box is not a toy or a learning curve for inexperienced people. I personally think that mentoring is down to the individual and based on his/her experiences. if you have developers who constantly screw up. it does influence your decision in what rights you give them. No developer should have access to a production box, and I believe that strongly. as a dba you have sole responsibility for production and your job rests on that. I also believe that developers should be able to do what they need to, in a development environment without restriction and if they need help they can ask a dba for it.]

So basically, a protector of the production environment and a mentor for the development environment. A good dba can be both. BigGrin

~Silverfox~

--------------------------------------------------------------------------------------
Recommended Articles on How to help us help you and
solve commonly asked questions

Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden
Managing Transaction Logs by Gail Shaw
How to post Performance problems by Gail Shaw
Help, my database is corrupt. Now what? by Gail Shaw

Post #772456

Andy Warren

Posted Tuesday, August 18, 2009 6:00 AM

SSCertifiable

Group: Moderators
Last Login: Tuesday, June 11, 2013 6:34 AM
Points: 6,463, Visits: 1,388

Organizations need both. No, we don't want developers experimenting on a production server, but they do need a sandbox where they can try whatever comes to mind. Whether that's a "real" dev server or a locally installed instance, they need that freedom.

In my view the 'lock it down' mentality often comes from a desire to avoid problems than a true desire for security. Very common for PC support people to do the same - don't let users change things like screen resolution because it might break something!

Security is serious stuff and shouldn't be dealt with lightly. But at every step we must also make sure our customers (the ones that pay and the ones that develop) can get to the data they need.

Andy
SQLShare - Learn One New Thing Each Day
SQLAndy - My Professional Blog
Connect with me on LinkedIn
Follow me on Twitter

Post #772597

Steve Jones - SSC Editor

Posted Tuesday, August 18, 2009 6:49 AM

SSC-Dedicated

Group: Administrators
Last Login: Today @ 3:19 PM
Points: 31,526, Visits: 13,863

Developers do need a sandbox, but they also need to maintain control of their dev environments. Too often they don't know what they changed to get something working, or they don't "undo" a previous change somewhere before making another one. That results in not an experimental system, but an unknown one.

I think Devs should have a person VM for really new changes and experiments, but either they or a DBA needs to maintain some control over changes in dev. Not to be too much of a protector or "lock it down" person, but to ensure those changes can be replicated later.

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #772635

david grace

Posted Tuesday, August 18, 2009 6:55 AM

Valued Member

Group: General Forum Members
Last Login: Thursday, September 10, 2009 8:27 AM
Points: 58, Visits: 21

I think a certain amount of freedom for developers in the test area is fine. Creating indexes, show plans, etc. are all part of giving them tools to help me help them get better faster code. But when it comes to creating tables, I'd lock that down. Most developers I've dealt with just don't understand how to normalize a database or (more likely) just don't care because their 3 rows of test data returned just fine while they were developing and once we test with load, the dba can make it better.

The problem is (at least here) once a developer writes code against their non normalized table that doesn't bother to follow naming conventions, that's it. They never want to have to revisit and change that code again. I just saw a new production table created while I was on vacation. It has 20 columns, 1 identity and the rest are varchar(max). Nice.

Post #772642

GSquared

Posted Tuesday, August 18, 2009 7:11 AM

SSCoach

Group: General Forum Members
Last Login: Yesterday @ 1:45 PM
Points: 15,442, Visits: 9,572

I favor a completely open playground, a slightly locked down dev box, and totally locked test, QA, and production boxes.

The playground is where you can try just anything at all. Should be a VM these days, with a "last good image" available to rebuild from in the case of "oops!" type situations. Probably need one per dev, but conflicting tests might be worthwhile too.

The playground is for proof-of-concept and hair-brained ideas.

Dev should be under source control, and should only have changes made that someone thinks will actually one day make it into production. But devs should have access to viewing execution plans, index use, et al, definitely, so they can refine code as they go.

Test and beyond should be locked down and shouldn't have anything on them that hasn't been through code review. They should replicate production as closesly as possible so that any effects can be tested in an environment that is as real as it can get. Thus, if production is to be locked down, then test should be too. Test and pre-release should have maintenance plans running on them, and backups.

That kind of set up makes sense to me.

As far as the relationship between devs and DBAs, I think it should be close. The DBAs should advise the devs on how to improve code and devs should advise DBAs on what to expect from upcoming solutions.

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

Post #772657

Andy Leonard

Posted Tuesday, August 18, 2009 7:15 AM

Old Hand

Group: General Forum Members
Last Login: Monday, June 10, 2013 12:27 PM
Points: 375, Visits: 950

Excellent points Matt!

I have to agree with most of the comments above. DBAs lock down development environments when someone makes a mistake that takes the development server to its knees. That's going to happen if people are allowed to experiment.

Folks have to be free to fail if they're free to succeed. It's part of the equation - the equal and opposite reaction, the give and take, upside and downside. I believe the benefits outweight the costs, but I know from experience there's a time and place to tinker and learn, and a time and place where that should not be permitted.

I like Steve's idea of virtual machines a lot.

I also advocate training application and web developers in a database development methodology. Teach them how to fish; start with how to bait a hook (write re-executable T-SQL) and prepare fish (use transactions when deleting / updating).

There's a fine line between beng a gatekeeper and a roadblock. Any given situation can appear to be either, depending on which seat you occupy.

:{> Andy

Andy Leonard
CSO, Linchpin People
Follow me on Twitter: @AndyLeonard

Post #772660

« Prev Topic | Next Topic »

45 posts, Page 1 of 5

1 2 3 4 5 »»»

Permissions