Re: How do you feel about allowing non-DBA's on your database servers?

This topic/debate is one of the oldest repeating threads I can remember.
Everybody thinks they absolutely cannot do their job without access to
production servers, whether it be through administrative control of the
application or, as you're facing here, access to the server at the operating
system level.

No.

Developers are paid to develop.  They try new things and break stuff.  It's
their job.  That's why we have development boxes.  They can do whatever they
want on those servers.  If they break it, it gets restored.  That's where
they create stuff and do unit testing before it gets sent to ......

A QA server where integration and probably user acceptance testing occurs.
If developers are part of the QA environment in the organization, they may
require some user permissions, but they don't fix anything in QA.  If it
doesn't work, they fix it in development and put it back into QA for
testing.  When it passes muster, then it gets put into production.
Developers need little or no access to production.  If there's a problem,
they should be able to replicate it on QA.  If they can't, that's where the
DAB and Sys Admin get ninvolved to see if there's something different with
the data or OS.

Support personnel might have limited access to production for some tasks
(re-setting printers comes to mind), but that is carefully controlled by the
Sys Admin(s).  Support personnel have no business looking at the data or the
database.  Usually, most of the problems support people encountered can and
should be fixed at the application level.

If folks are worried about monitoring, there are a variety of user-friendly
(pretty picture) products out there that can provide system-level monitoring
to interested personnel with them having access to the production server.
Some are free, some cost money.

Bottom line is that the decision rests with management.  There are SOX
implications if you are dealing with a public company.  There are business
issues regardless.  Production is called that for a reason.  We process $1M
/hour in orders through our systems.  Believe me, nobody from the
development side of the house has any access, system or application, to any
of the servers.  For certain issues, support people have 'firefighter'
access to the application, but they have to request it, it's approved by a
manager, and their actions are logged.  For other issues where advice from
the development teams is need or wanted, an application administrator, DBA
or Sys Admin sits with them while they have access.

There's a reason production is called production.  It's generally the
lifeblood of the firm.  It needs to be as secure as possible.

On Mon, Jul 27, 2009 at 11:31 AM, Robert Freeman
<robertgfreeman@xxxxxxxxx>wrote:

> So, I've got a client that is being pressured by development and support
> types to allow access to their database servers. They claim that it's so
> they can use tools like ps, sar, topas, etc.... to monitor performance and
> deal with support issues.
>
> My position is that this is a huge risk and that I would want an very
> limited population of users (read DBA's and SYSADMIN's only) to have access
> to these servers.
>
> Anyone have an opinion on this?
>
> RF
>
>
> Robert G. Freeman
> Oracle ACE
> Author:
> Oracle Database 11g RMAN Backup and Recovery (Oracle Press) - ON IT'S WAY
> SOON!
> OCP: Oracle Database 11g Administrator Certified Professional Study Guide
> (Sybex)
> Oracle Database 11g New Features (Oracle Press)
> Portable DBA: Oracle (Oracle Press)
> Oracle Database 10g New Features (Oracle Press)
> Oracle9i RMAN Backup and Recovery (Oracle Press)
> Oracle9i New Features (Oracle Press)
> Other various titles out of print now...
> Blog: http://robertgfreeman.blogspot.com
> The LDS Church is looking for DBA's. You do have to be a Church member in
> good standing. A lot of kind people write me, concerned I may be breaking
> the law by saying you have to be a Church member. It's legal I promise! :-)
> http://pages.sssnet.com/messndal/church/parachurch.pdf
>
>

Other related posts: