By my experience the co-operation sysadmins and developers works best if they are put together in one team. Either as a release team or a project team.
Because if they work close together they start to understand what the each of them is doing and why there is sometimes a gap in between duration of tasks.
The simply reason for that is, that when they sit together in one room working on exactly the same scope they will start to talk with each other. And perhaps they will also share some time (like lunch or even some after-work event) with each other.
So, mutual respect will grow automatically.
Of course this will not work of all kind of people … because you will still find some lone-wolves, who you do not want to miss because of their skills.
The secret is to work with them, not against them. You as a programmer have a need. They as a sysadmin should be able to satisfy that need in a way that is acceptable to them. That usually means finding what the real need is, and setting up a process for it.
For instance, blatant open access to one of the assets they control is not going to happen. But common tasks that you need to accomplish on that asset can have a process created.
I have basically the same issues with ServerAdmins and Support Reps. Our shop is so screwed up support reps that barely know how to use their PC with XP/Win7 are allowed to remote into our server environment to run business applications and make configuration changes!
Microsoft doesn’t help this mentality with “the server looks just like my desktop so it must be the same”. I really wish WIn 2003 and 2008 server was totally command line driven so users had a huge learning curve!
The reason to give access is because a bad sysadmin is a process bottleneck.
The reason not to give access is that programmers break things.
There is one essential rule for each role:
Sysadmins: Lead, follow or get out of the way.
In other words, don’t be a roadblock.
Take a proactive role in each project, or be prepared to do pretty well whatever they want.
Programmers: Bad planning on your part doesn’t constitute an emergency on mine.
In other words, your project isn’t the most important thing in the world, and don’t expect a sysadmin to jump through hoops to help you. Get Sysadmins in at the planning and design stages so you know what IT problems are pending.
@Matt Langley, I agree. It strongly depends on the size of your company. in small companies, sysadmin role is normally given to a highly responsible person of the team, able -and like to- to monitor and prevent any server faults and to scale hardware as necessary.
However, both scenarios are very different. and the sysAdmins meadows and programmers mountains need very different kinds of persons too. so at the end you will need to train and keep with you somebody dedicated full time to the task, for the sake and peace of your company -and the mental healthy of the sysAdmin ;).
I completely agree that developers should not be given access to production systems. A solution or system architect, depending on what vernacular you’re using, is a completely different story.
As someone operating in said role, it’s exceptionally infuriating having to deal with a client’s operations group that generally has poor experience operating servers. For example, my current customer’s operators thought that having 0 free disk space was okay. Nevermind that virtual memory couldn’t be allocated. The same group also found it appropriate to arbitrarly change file permissions on a server which broke the application in question. Oh, and the brilliant production DBAs threw tempdb on C:\ (RAID-1) which brought the site to a screeching halt. All of this on an application that generates $10s of million in revenues per day. Whoops.
So as a system admin there are a couple of things that can be done to help those that sit in the middle or completely on the dev side sleep at night.
First - be competent and be open about what’s being done to servers.
This rarely happens unfortunately (in both aspects). Referring back to the file permission issue above (which was causing a CPU spike) - the operations group absolutely refused to believe it was something they did, in spite of numerous performance charts that could pin down exactly when something happened. So instead, developers spent 2 weeks scratching their heads and wasting a lot of money until ultimately someone remembered that they did something when they ran an analyzer on the server. Seriously - they blew probably upwards of $100k because someone didn’t write something down and fill out the proper paperwork.
Secondly - just make the information available to us!
There are big boy and girl toys like SCOM and OpenView which can give everyone insight into what’s going on without requiring setting up some absurd scheme to allow us to remote into boxes with some form of read-only access. More importantly, those tools let us know that it’s about to hit the fan well before it actually happens and can capture knowledge to resolve issues in the future as well as trend tracking which is invaluable. Spend some money to save many orders of magnitude more in the future by investing in these tools, preferably in conjunction with some sort of profiling capability (e.g. AviCode, dynaTrace,etc…).
On the development side of the house…
Construct your applications to be operationally friendly. Instrument them. Provide proper event log entries (i.e. don’t flood it with 10k entries / sec of useless crap). These all play well into being able to determine what’s failing in a system - your lack of ability to account for this is your own fault and further reinforces the fact that you should not be given access to the system (SAs aside in the event of emergencies). Create run guides. In short - be professional, competent developers and architects. If you publish all the necessary information from your application, it’s generally nothing more than admins capturing it and publishing it through one of the aforementioned tools. If you don’t, you have nobody to blame but yourself.
