> At my company devops is primary on-call, with a developer(s) as backup

Sort of defeats the purpose of Dev ops, if you have a Dev ops team and a Dev team, doesn't it?

Does it?

Dev Ops is focused more on operations (tooling around releases, monitoring, etc) as well as doing initial triage for system problems to figure out where the problem is, and if they can't fix it themselves, determine which engineering group can help resolve an issue. Most of the Devops staff does development, but more around operational needs, product features are implemented by Dev.

Dev Ops means different things to different companies.

I think it's fair to say that you're just ops since you have the exact same functional role. And you can suffer from the same organizational issues that prompted the creation of the devops movement.

That said, there's a need for a way to divide the industry between traditional ops people and those with the ability to handle modern infrastructure and develop custom tooling where needed. And for better or worse the industry has decided that "devops" is going to be the way to determine that. Now the problem is all of the fakers (both individuals and teams) adopting the moniker. So now we're back to square one and we actually need to evaluate people and teams based on their knowledge and skill.

We're more integrated with Dev than a traditional "ops" role where Dev throws the code over the fence at Ops and says "Deploy it!" and Ops throws it back if there's a problem and says "Fix it!"

Our devops team sits in on design and code reviews to help ensure that operational needs are met early on in the process, and we'll change code to fix bugs or support operational needs. We're not full developers and won't rearchitect entire systems, but we will do bug fixes when we can.

So now we're back to square one and we actually need to evaluate people and teams based on their knowledge and skill

Have we ever left that square?

Sounds like your devops and dev teams do devops which is great. I wasn't trying to imply that they don't or that they had the same problems that prompted the movement, only that your roles are divided the same way as traditional dev and ops even if you do in fact do them smarter than average. What I'm getting at is that "devops" as a title is an (internal) marketing term.

You're right that every org defines devops differently but it's totally and unashamedly coopted from a movement which, despite being very generally defined, defines it radically differently. And that's not to say it's always a bad thing either. Sometimes it takes a title to help signal change and make an organization better which in the end accomplishes the goal of the movement.

And I agree, I don't think we ever left that square and we never will. But if prepending "dev" to "ops" wasn't at least somewhat effective in getting something out of people in decision making positions it wouldn't be tacked on to job titles and team names left and right. So at least some people think the marketing terms in a job title are a meaningful shortcut even if smart people like you know better.

Yep. This is how my org does it. DevOps builds automation/tooling to help the operations focused developers on the dev teams do their jobs better.

The word Devops means that the Dev team is the Ops team. If you have both teams, you are defeating the purpose of DevOps

Actually devops is supposed to be a culture where the dev team and ops team work together. What people seem to want it to mean is you're an ops team with automation skills. I've yet to see this be a dev team doing ops.

It goes a bit beyond "an ops team with development skills" in my company -- someone from Devops sits in on design and code reviews to suggest changes for operational needs (which almost always means adding metrics so we know how busy it is, and when it breaks or is near breaking, followed closely by adding enough logging so when it does break, we know why and don't need to page a developer to read a stack dump to try to figure it out).

But ultimately, the developer is the one that best understands how their code may break so he needs to instrument the code accordingly. And when the developer knows that giving the right information to Ops may avoid a 3am phone call, they have good incentive to do so.

Typically a DevOps team would mean a team that works on things that make it easier for the whole organization to do DevOps, e.g. tooling for easier building, deploying, testing, configuration and monitoring. It doesn't defeat the purpose of DevOps unless the people at the organization think that it's the only team that needs to be doing DevOps.

If you have a DevOps team you are doing it wrong.

So much this. I don't trust an engineer who's never done maintenance work. And I really don't trust an engineer who's never been on call. I find that they write vastly different (usually much simpler) systems. Personally I will now only build a system that I know I can troubleshoot at 4am while drunk.