Networks

Ask something
Discussion Locked

Developer Access to Production Servers

0 helpful
6 replies

by jdouglas99

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.
We are having ongoing debates initiated by the development side on granting them full access through remote desktop to production servers for after-hours support. Their argument is they can get the users working faster without having to work with IT support to make the needed changes, but IT support is concerned with changes being made to production without their knowledge or ownership since IT is ultimately responsible for server uptime. How does everyone else handle programmer access to production boxes?

6 replies

by genera-nation

So what is the issue here. Out of Hours support - there is no development in that.

Developers can develop on the test servers, once the developments have been tested on the test servers they are applied to the real ones by IT alone or IT & the Developers, not the Developers alone.

Long story short - they do not get access to develop on production boxes.

by madestroitsolutions

This is an ongoing debate for many companies out there. It really depends on your internal SOP's, IT's response time, the kind of application being run, application's stability, etc etc.

Normally, you would want to keep the developers out of the boxes as IT is responsible for the servers. However, in real life sometimes things come up that are related to the application rather than the server that require troubleshooting. For such instances, it is definitely a plus to allow developers to access the boxes rather than have them blindly tell you what to do over e-mail or phone.

All in all, you should ask yourself the pros and cons and if there is real value on them accessing the box. If the errors you encounter are machine or configuration related and you can take care of them on your own or with minimal support from developers, then it makes no sense to have them access it. If you find most of the troubleshooting involves them giving you instructions over the phone fro two hours then you are better off giving them access.

Some companies have well structured SOP's in place and simply do not allow developer access at all.

Many people (specially in IT departments) don't like this approach because they somehow feel threatened by it, not because the machines are exposed to developers, but because they feel they loose control over things.

Now, my personal take on the subject:
Developers are not out there to break things. They are simply trying to get things running and help people out.
I should mention I am a Sr. Web Developer. After having worked in large as well as small companies, I can tell you in terms of productivity my personal opinion is developers need access to boxes in order to deploy, install, configure and troubleshoot software in an efficient and timely manner. You should try to get to an agreement with them as to what they can and cannot do with the box. You want them to be able to access it but you don't want them installing software or rebooting the machine without your permission.

Good luck!

by genera-nation

You do this on the development boxes not the production servers (unless the production is down and a fix is in progress)

by george_1776

I understand the need for auditing of everything that touches production, and the need for multiple parties to be involved in changes whenever possible. But I am floored at the trust people place in "systems" groups. These people are every bit as capable as developers of doing things that are bone-headed, stupid, or wrong. Not to mention dishonest.

If the view is that developers are somehow more "dangerous" because they have knowledge of the inner workings of the application and database guess what: keeping them out of production doesn't change that. If you don't trust your developer fire him. If he's trying to steal data or sabotage your application he'll do it whether he's got access to production or not. He writes the code that goes to production - that's all the access he needs.

Ideally no one should have access to production without an audit-trail and oversight. In addition people with production access should be carefully chosen. Time with the company, maturity level, and trustworthiness are all key factors. Whether that person is a developer or a system admin really doesn't make a difference.

by tony hopkinson

I've been a developer in this position and it can work.
But

I was on the same same bonus as the production operators.

I had to deal with them, big hairy tattooed f'wits in my case, daily.

If it went nipples up at 2 am, It was me who got woken up to fix it and there was no overtime / call out fee.

If you want to be more reactive, by all means give them access, once you've set it up so being called upon costs's them money. (I used to get a percentage for being on call, if I didn't get called out, I was a winner)

Otherwise train your support staff and tool up as required.

by mrbunch

I grew up as a developer and am now an IT director over software developers. Our company just got bought and now I have half of my staff under a restrictive, no-access model and half under a total access model. While I completely understand the Segregation of Duties argument, the implementation of our restrictive model prevents nothing as far as I can tell. The process for giving a developer access the production server goes something like this:
1. Developer says "I need access to a production server."
2. Server guys say "okay, you're logged on (as an admin by the way)."
3. Developer does whatever.

The same applies on moving code. The developer says move this code, the server guy moves the code. The server person has no idea what is being done and as far as I can tell doesn't care. It also doesn't appear to be logged anywhere, so I'm not sure what it is preventing other than quickly resolving problems. I honestly don't see how this would be useful other than with the logging of activity on the production boxes, which seems like it would need to be done whether you implement the prevention of access control or not. If my programmers are going to production too much and screwing things up, I have motivation to fire them for messing with the business.

Thoughts?

This discussion is closed to new replies.