My devs all have access to production. They always had and they feel they
should still just in case they need to resolve issues.
Are there any articles on how I can convince them to get out and stay out
Let me know what should i tell them so I can revoke their access
Thanks
if you don't trust someone; hand them specifically what you want them to work on
and nothing else.
I've worked on *MANY* large scale production systems. I've never had "100%
access to 100% of the project".
If they're your devs, "here's the way it is".
I recently pointed out a small bug in an application. would take 2 seconds to
fix. (typo in a dialog).
I am *NOT* to change anything w/o a bug being written up & published.
It was, but said "do not change it unless you're working on that module for
something else".
The problem will be there for upwards of 3+ months because that module is rock
solid. Point? it's what I was told to do as a developer.
Tell your devs they'll get access to what they need.
Now; once you do -- live wit hthe fact that things don't happen as fast and the
backlash of "I couldn't resolve the issue, so-and-so had rights, not me." You
will have created the situation.
On Mon, 30 Jan 2006 20:30:23 -0800, "Hassan" <Hassan@.hotmail.com> wrote:
>My devs all have access to production. They always had and they feel they
>should still just in case they need to resolve issues.
>Are there any articles on how I can convince them to get out and stay out
>Let me know what should i tell them so I can revoke their access
>Thanks
>
-- AntiSpam/harvest --
Remove X's to send email to me.
|||A hammer, baseball bat, or golf club come to mind. So does, "I'm
responsible for it now". There isn't an easy answer. This is pure politics
that can really be argued both ways. My basic answer is that unless someone
is going to be held accountable for maintaining a database, they shouldn't
have any administrative authority. "Just in case" is just an excuse for
"please don't take away my toys".
I usually fix it by simply handing developers a pager. When they ask what
that is for, I tell them that since they have access to the production
database, that also make them responsible for it. Since they are
responsible for it, they also have to carry a pager and be woken up at 3AM
when things go wrong. Access is usually revoked within a day of doing that.
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Hassan" <Hassan@.hotmail.com> wrote in message
news:uK3TO8hJGHA.740@.TK2MSFTNGP12.phx.gbl...
> My devs all have access to production. They always had and they feel they
> should still just in case they need to resolve issues.
> Are there any articles on how I can convince them to get out and stay out
>
Let me know what should i tell them so I can revoke their access
> Thanks
>
|||:-)
I like your style. I may have to try that myself (it's an ongoing issue
where I work - I'm pretty solid on the SQL side of things but not great
on the political side of things).
*mike hodgson*
http://sqlnerd.blogspot.com
Michael Hotek wrote:
>A hammer, baseball bat, or golf club come to mind. So does, "I'm
>responsible for it now". There isn't an easy answer. This is pure politics
>that can really be argued both ways. My basic answer is that unless someone
>is going to be held accountable for maintaining a database, they shouldn't
>have any administrative authority. "Just in case" is just an excuse for
>"please don't take away my toys".
>I usually fix it by simply handing developers a pager. When they ask what
>that is for, I tell them that since they have access to the production
>database, that also make them responsible for it. Since they are
>responsible for it, they also have to carry a pager and be woken up at 3AM
>when things go wrong. Access is usually revoked within a day of doing that.
>
>
>
|||You can state several reason, and that depend upon
1. criticality of your data
- If some dev, run an update and mess up your data you need to restore
last back up and transaction log just before update happend. Then you need to
keep your server offline, will that affect your business? then thats a good
reason.
2. Size of your data
- If data is huge, restoration of corrupt data can take much time
3. Routine maintenece
- As admin you got routine maintenece , also you may go for process
where DB should be in single user mode.
Again why cant you go for an arhictecture where you have
=> Development Server
=> Integrated Server
=> Prodcution Server
Take daily backup from production, and restore it in Integrated Server. Give
dev access to integrated server, so that they will get the recent data from
production. Do the fix and apply that in production.
Thanks,
Sree
"Michael Hotek" wrote:
> A hammer, baseball bat, or golf club come to mind. So does, "I'm
> responsible for it now". There isn't an easy answer. This is pure politics
> that can really be argued both ways. My basic answer is that unless someone
> is going to be held accountable for maintaining a database, they shouldn't
> have any administrative authority. "Just in case" is just an excuse for
> "please don't take away my toys".
> I usually fix it by simply handing developers a pager. When they ask what
> that is for, I tell them that since they have access to the production
> database, that also make them responsible for it. Since they are
> responsible for it, they also have to carry a pager and be woken up at 3AM
> when things go wrong. Access is usually revoked within a day of doing that.
>
> --
> Mike
> http://www.solidqualitylearning.com
> Disclaimer: This communication is an original work and represents my sole
> views on the subject. It does not represent the views of any other person
> or entity either by inference or direct reference.
>
> "Hassan" <Hassan@.hotmail.com> wrote in message
> news:uK3TO8hJGHA.740@.TK2MSFTNGP12.phx.gbl...
>
>
|||Hi Mike
Something that I don't think has been specifically mentioned is
accountability, it is not the same as trust, because you can give developers
access to the production system but only in a contolled manner, and only to
make changes that have been passed as fit i.e. been through the a test cycle.
The other thing is sensitivity, the more open the access is, then the
greater the risk of a violation. Whoever carries this risk should be aware of
the situation.
If your developers do not have access to a production system, there should
be an equivalent system that can be used if the need arises. If your data is
sensitive, then this alternative system can be de-sensitized.
John
"Mike Hodgson" wrote:
> :-)
> I like your style. I may have to try that myself (it's an ongoing issue
> where I work - I'm pretty solid on the SQL side of things but not great
> on the political side of things).
> --
> *mike hodgson*
> http://sqlnerd.blogspot.com
>
> Michael Hotek wrote:
>
|||That's really the basic point behind handing developers a pager or whatever
you use. People always seem to want administrative access to things without
having any of the responsibility. You simply make it a point that if they
want admin access, of any kind, then they are going to be just as
responsible for the system as you are. That means every time something goes
wrong on the system, they get yanked into it right along with everyone else.
The rest is left unsaid, because it doesn't need to be. It's making a very
fine point about why certain people have admin access and no one else does
without getting into a big argument about it.
When you boil it all down, there isn't a single reason that someone can come
up with that I couldn't argue both sides of. It has nothing to do with data
volume, operations that are executed, errors that are found, change control,
etc.
The only issue that can't be argued is responsiblity. If you have admin
access, that means you are responsible for the system, period. If you give
someone admin access without also requiring them to be responsible for the
system, then you might as well get used to sleeping in your office.
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:57A3D790-44EB-403E-AFEB-7CC922094886@.microsoft.com...[vbcol=seagreen]
> Hi Mike
> Something that I don't think has been specifically mentioned is
> accountability, it is not the same as trust, because you can give
> developers
> access to the production system but only in a contolled manner, and only
> to
> make changes that have been passed as fit i.e. been through the a test
> cycle.
> The other thing is sensitivity, the more open the access is, then the
> greater the risk of a violation. Whoever carries this risk should be aware
> of
> the situation.
> If your developers do not have access to a production system, there should
> be an equivalent system that can be used if the need arises. If your data
> is
> sensitive, then this alternative system can be de-sensitized.
> John
>
> "Mike Hodgson" wrote:
|||Hi Mike
I think what I was pointing out was from the other direction, the developers
may want access to the company payrole, but will whoever is responsible for
it want them to have it? I.e. you may need to find the person who is
responsible and say "Do you want them to do this?"
John
"Michael Hotek" wrote:
> That's really the basic point behind handing developers a pager or whatever
> you use. People always seem to want administrative access to things without
> having any of the responsibility. You simply make it a point that if they
> want admin access, of any kind, then they are going to be just as
> responsible for the system as you are. That means every time something goes
> wrong on the system, they get yanked into it right along with everyone else.
> The rest is left unsaid, because it doesn't need to be. It's making a very
> fine point about why certain people have admin access and no one else does
> without getting into a big argument about it.
> When you boil it all down, there isn't a single reason that someone can come
> up with that I couldn't argue both sides of. It has nothing to do with data
> volume, operations that are executed, errors that are found, change control,
> etc.
> The only issue that can't be argued is responsiblity. If you have admin
> access, that means you are responsible for the system, period. If you give
> someone admin access without also requiring them to be responsible for the
> system, then you might as well get used to sleeping in your office.
> --
> Mike
> http://www.solidqualitylearning.com
> Disclaimer: This communication is an original work and represents my sole
> views on the subject. It does not represent the views of any other person
> or entity either by inference or direct reference.
>
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:57A3D790-44EB-403E-AFEB-7CC922094886@.microsoft.com...
>
>
|||On Mon, 30 Jan 2006 20:30:23 -0800, Hassan wrote:
>My devs all have access to production. They always had and they feel they
>should still just in case they need to resolve issues.
>Are there any articles on how I can convince them to get out and stay out
>Let me know what should i tell them so I can revoke their access
>Thanks
>
Hi Hassan,
A lot of good ideas are mentioned already. But I've missed one so far:
in many countries, privacy laws require you to limit access to
production data to only those who absolutely need it. Developers don't
need permanent access to production data.
(They may sometimes need temp access to prod when troubleshooting a
production error - they should use a special login that is normally
disabled, fully logged, and they should ideally be constantly monitored
while fixing the problem - though the last requirement is somewhat
unrealistic).
Hugo Kornelis, SQL Server MVP
|||I understand, that's a much different issue that's really easy to fix. When
you have sensitive data, that's a simple case to restrict access that no one
can argue with. It's the cases that don't fall into that category that are
more difficult.
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:2A73DAF3-A001-4927-94D7-051852672CA3@.microsoft.com...[vbcol=seagreen]
> Hi Mike
> I think what I was pointing out was from the other direction, the
> developers
> may want access to the company payrole, but will whoever is responsible
> for
> it want them to have it? I.e. you may need to find the person who is
> responsible and say "Do you want them to do this?"
> John
> "Michael Hotek" wrote:
chemas-microsoft-com
ffice:excel">
ivotTable>
isplayScreenTips /> 
Praveen Dayanithi wrote: