[venomsnake]

The developers should know how to do ops. And vice versa.

We are moving into weird heterogeneous bugs territory. A lot of stuff that has wasted my time last year was caused by interaction of technology stacks and not by pure logical errors. Or error localized in even one package.

I had problem with premature socket close on the response with just the wrong setup for all of nginx, haproxy, slim and php 5.4 ... lets pure ops or pure dev figure that out.

[pessimizer]

Whatever part of dev/ops that applies to me personally is very much tied up in 'full-stack' debugging of intermittent performance problems and heisenbugs.

I rely on the ops guys to keep vanilla installs steady and to keep everything patched, but there's very little way that they can get insight into application problems (especially in the framework du jour) that express themselves at some other location in the stack. I just have to know the whole thing.

[festivusr]

The ops people you work with are also developers? That sounds great but has never been the case at anywhere I've been.

[venomsnake]

They are not developers - they have no rights to write commit and promote code but they are good enough at reading it to not be helpless when something breaks down and they need to take a peek what has changed recently in the codebase and stuff like that.

I on the other hand have no admin rights (only read access) but I know enough of out network and ops structure to be able to make an educated guess when something is behaving strange.

So if it hits the fan they could probably patch an emergency bug and I could fire up some VM instance. It is not about wearing a lot of hats, but being able quickly to put on a new one if needed.

[nogbit]

Try working on small teams, very small teams. There is no way around it, you must wear multiple hats, and those hats grow/change over ones career.