[hnlmorg]

Then that would be a sysadmin / DevOps responsibility rather than your application developers. Or at least you'd have those guys involved with the investigation.

But honestly, how often is a web applications bug due to a kernel bug?

[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.

[Aeolun]

Yeah, ever since devops became a thing they’ve placed themselves in this position where they’re somehow better than the application developers, even though until a few years ago those same developers were doing the exact same things.

I swear, sysadmins were annoying as an application developer, but devops is something else.

People with one year of actual work experience get hired as devops, and have all the privileges I would need to fix their mistakes, but I can’t, because I’m an ‘application developer’. So instead you end up teaching them how to do their job.

I’m not salty at all.

[emptysongglass]

DevOps is a set of practices not a role. I do Ops, practicing DevOps, and I serve my programmers. My job is to ensure they stay happy. If they're not happy about something in the production pipeline that's on me. I work hard to make sure that I'm their Jesus Christ for all things infrastructure.

If your programmers aren't delighted with you, I'd say you the Ops person is not practicing DevOps or you have a buy-in problem to DevOps practices at an organization level.

[monkey34]

I love this take.

My previous role had my title as "DevOps Engineer" but it always rubbed me the wrong way. I was just an Operations Engineer with a focus on making my developers' jobs easier, in any way I could. Having that as my North Star kept me honest about the work I was doing versus considering the role more like Operations Engineer v2.0.

In the Silicon Valley, at least, DevOps seemed to be (seems to be?) sort of in vogue; I think it's important to keep its core qualities of bridging Development and Operations in mind as opposed to just shifting an existing position's title in an attempt to attract talent.

[peterwwillis]

Preach!!

And this should extend throughout the organization. If Architecture or Security or any other group is making your life miserable, they too should be DevOps'ing, working closely with you, caring about your frustrations that only they can fix. Sadly there are still so many silos left to break up.

[ralmeida]

Agree, a job title of “DevOps Engineer” is an organizational smell for me.

Most people with such a title are actually something like “Automation Engineers”, “Infrastructure Engineers”, “Operations Engineers”, “Site Reliability Engineers”, etc, that are involved in a DevOps “process”, “initiative”, “culture”, etc.

[xref]

Ah the classic ivory tower argument where some “other class” of engineers are universally inept, but not “my class!”

You can write the same screed full of generalizations from the perspective of any job title: a devops person would lament the fresh-out-of-bootcamp “application developers” who have no idea how systems work together so write SQL queries that retrieve a million rows, one at a time. “Works on my local!”

[hinkley]

Pretty sure GP was bristling at the reverse happening. We must keep the developers from screwing up the important computers.

Saying the emperor has no clothes is not white tower thinking,

[Aeolun]

I completely agree. Access to those things should be given to those qualified to work with them, not based on an arbitrary role designation.

[laumars]

I’m sorry you’ve had some bad experiences but not everyone is like that.

However it’s also misguided to assume that specialities don’t exist. You can have infrastructure guys, developers, security folk; and there will be overlap between each role but it’s impossible to be the master of each trade.

I agree that arrogance is an unpleasant trait but arrogance can take many forms, rudeness to colleagues, or over assuming ones own technical capabilities in adjacent fields.

[Mandatum]

I've yet to find many organisations that split those responsibilities up enough. This might work for 1% of orgs, wait no - 1% of tech orgs, but everyone else needs something better.

[hnlmorg]

I can't vouch for your experience but as a sysadmin myself I've found 100% of the companies I've worked for has had dedicated sysadmins ;)

I'm being a little flippant here though, I am aware that developers are often asked to wear the sysadmin hat too.