[closeparen]

a) How can there be a "DevOps responsibility rather than your application developers"? Isn't the whole idea of the word "DevOps" to eliminate such distinctions?

b) In my experience, the application developer is held responsible for the application's behavior in production. In the luckiest .01% of scenarios, there might be an infrastructure engineer with appropriate permissions and free time trolling the Slack support channel at the moment you report the issue. Otherwise 99.99% of the time infrastructure will not acknowledge of investigate anything complicated or subtle with just one service owner complaining. The infrastructure group, organizationally, is graded on shipping new platform features and on coarse KPIs for the performance of the platform as a whole; nobody is getting paid to investigate the weird bugs of some application team somewhere.

[paranoidrobot]

> Isn't the whole idea of the word "DevOps" to eliminate such distinctions?

No, it doesn't eliminate such distinctions. My view of DevOps is more about ensuring that automation is used as much as possible to meet objectives.

It's definitely not about making everyone a homogeneous developer unit that can work on every problem.

People come in all shapes and sizes, some are more competent with certain things than others, others have a lot more experience with certain things. That's aside from the whole preference thing - not everyone wants to or has an interest in managing infrastructure.

Maybe when you have a handful of developers and a small set of infrastructure, that's fine - but at a certain point you start to require more and more specialised knowledge. Yes, even when you're all-in on Cloud and using all the SAAS/PAAS products out there.

>Otherwise 99.99% of the time infrastructure will not acknowledge of investigate anything complicated or subtle with just one service owner complaining.

Yeah, that's an organisational problem from the sound of it.

[dijit]

Everyone having their own idea of what devops means is problematic.

I think it’s best to consider the original source which is this talk from Flickr: https://youtu.be/LdOe18KhtT4

("10+ Deploys Per Day: Dev and Ops Cooperation at Flickr").

Directly it talks about joining developers and operations into the same team- later Patrick Debois would refer to this as DevOps and a year later the first DevOps days in Ghent was organised (also by Debois).

[dasil003]

Thanks for reminding me that someone else remembers this. It seems like it took no more than 5-6 years for everyone to simply adopt the term as a replacement for sysadmin with no change in operational practices. Coincident with that it seems most infra engineers started calling themselves SREs to distance themselves from the diluted concept.

[peterwwillis]

Yep. It's more of a concept of cooperation than anything else. Which, since it's not a concrete thing, makes it harder for people to understand. But then there's specific practices that arose out of trying to drive best practices in Ops at the same time (like IaC, II, CattleVsPets, automation, etc) so now DevOps "means" a jumble of slightly related things.

We really need some new terminology.

[mongol]

Is that the original devops talk, which is like the origin if the devops "movement"? Very cool, did not know it had such a clear origin.

[thayne]

At my company, a subset of developers have ssh access, if other developers need something that requires ssh access they work with someone who has it. But unless you are a very early startup, I don't see why every developer would need ssh access.