Production Access Denied! Who caused this rule anyways?

One of the biggest challenges for developers is getting access to production servers. In smaller dev teams of 5 or less people everyone usually has access. Then you hire developer #6, he messes something up in production… and now nobody has access. That is how it always starts. Just about every rule in life gets created this way. One person messes it up for the rest of us. Rules are then put in place to try and prevent it from happening again.

Breaking the rules is in our nature. In this example it is for good cause and a necessity to support our applications and troubleshoot problems as they arise. So how do developers typically break the rules? Some create their own method to collect log files off servers so they can see them. Expensive log management programs can collect log files, but log files alone are not enough. Centralizing where important errors are logged to is common.

Some lucky developers are given production server access by the IT operations team out of necessity. Wait. That’s not fair to all developers and knowingly breaks the company rule!  When customers complain or the system is down, the rules go out the window. Commonly lead developers get production access because they are ultimately responsible for supporting the application and may be the only person who knows how to fix it.

The problem with only giving lead developers production access is it doesn’t scale from a support standpoint. Those key employees become the go to people to help solve application problems, but they also become a bottleneck. They end up spending up to half of their time every day helping resolve application defects, performance problems, or whatever the fire of the day is. This actually the last thing you want your lead developers doing. They should be working on something more strategic like major enhancements to the product. Having production access can actually be a curse if you are the guy stuck hunting down log files all day.

Application defects are good tasks for junior developers. They can usually handle figuring out simple application problems. But nothing is worse than being a junior developer who can’t figure out those problems and the back log of them grows and grows. Some of them require production server access to verify a deployment was done correctly, verify config settings, view log files, or maybe just restart an application. Since the junior developers don’t have access, they end up bugging the developers who do have access or they track down a system admin to help. It can take hours or days to see server information that would take seconds or minutes if they had access of their own. It is very frustrating to the developer trying to solve the problem, the system admin being forced to help, and most importantly your customers who are not happy about the situation. This process is terribly inefficient.

Production database access is also important for solving application problems, but presents a lot of risk if developers are given access. They could see data they shouldn’t.  They could write queries on accident to update data, delete data, or merely select every record from every table and bring your database to its knees. Since most of the application we create are data driven, it can be very difficult to track down application bugs without access to the production databases.

Besides it being against the rule, why don’t all developers have access? Most of the time it comes down to security, change of control, lack of training, and other valid reasons. Developers have been known to tinker with different settings to try and solve a problem and in the process forget what they changed and made the problem worse. So it is a double edge sword. Don’t give them access and fixing bugs is more difficult, or give them access and risk having more bugs or major outages being created!

Stackify is dedicated to solving this problem and giving all developers the limited and secure access they need to provide agile support.

Author

mwatson

More articles by mwatson