- Welcome to the Jungle Baby!
- Pigs In Space
You’re here so you already know who won. Pigs in space? Pigs don’t belong in space?!?! That’s work for dogs, monkeys, and humans, right? Well I’m sure some of you were just as aghast last week when you heard Chet aka @oraclenerd talking about developers in production.
In Chet’s post, I was quoted as playing both sides a bit. This is because I have played both roles. In the end I came out and declared that in the ideal world, developers would have no access to production instances. But since we don’t often live and work in the ideal world, I want to discuss some possible reasons developers would have access to production. I invite @oraclenerd to take up the opposing counterpoint on his blog 🙂
Top 10 Reasons You Might Find a Developer in Production
1: They Are Already There
That’s right, the previous administration decided at some point to let the developers in. Getting them out now is going to be problematic. They are probably going to say they can’t do their jobs without having access because they are used to having it. They may or may not have valid reasons. Don’t assume they are wrong. Maybe it’s because…
2: There is No Dev – Test – Prod Delineation
You will find a nice, clean, and separate ‘here is where we code, here is where we test, and here is where we have users running around’ ecosystem in most shops. However, I have visited more than a few places where you might have only one or two of these. I would argue this is much worse than having developers running amuck in production. Treat the condition, not the symptom.
3: Wearers of Multiple Hats
Smart people often fill more than just one role in an organization. They write application code, but they also help out with support and migration and upgrade scripts. They may even serve as a local DBA for their development instances. You can let one developer in without letting them all in, assuming they are there at your behest. I would hate working somewhere where my job title or label prevented me from helping the organization wherever my talents lended themselves to do so. Accidental DBAs, please raise your hand. Now take a picture, and email it to us so we can see it. I’ll just assume you are out there if I don’t get any pictures…
4: Putting Out Fires
It would be hard to argue that no one knows more about the inner-workings of an application than the person who wrote the application. It may become necessary for a DBA to go to a developer when they have exhausted all of their tricks when tracking down bugs and performance problems. Most developer will refuse to even look at a bug report without the appropriate logs and environmental information. If the problem is on-going and VERY painful, it might just be easier to give them access to the database. This assumes that:
1: They can be trusted with confidential information (or such information is protected via privileges)
B: They already know their way around the data dictionary v$ objects.
5: Your Security Sucks
If a developer wants something, they are smart enough to figure out how to get it. The ethical ones will generally stay away from places they are not supposed to be. But if you have a production database with weak or default passwords, a developer might just assume they’re allowed to be there. There are other ways to access a production database outside the proper channels, but I don’t want to give away too many secrets. Developer know how to use Google. Don’t tempt them by making it easy. And if you find them, warn them and patch up your holes, or it will be more than just their job on the chopping block.
6: It’s Only Kinda Prod
Reporting instances that are copies of production. Generally built to off-load the reporting overhead from the actual production instance. Built for all of the data nerds in the company. Accountants, bean counters, business analysts all need to run their ‘SELECT * FROM…’ queries somewhere, right? If you have developers tasked to building reporting interfaces or doing ETL work, you might find them here. This is a corollary to the previous ‘There is No Dev – Test – Prod Delineation’ rule. Can you trust your developers with the business critical data? If you are dealing with Health Insurance Portability and Accountability Act (HIPPA), I wouldn’t risk it.
I’m going to leave some space here at the end for others to fill in. Mostly because I’ve covered the the obvious ‘loopholes’ and I’m sure there are plenty of bright people out there that can share their own personal experiences here.