Consulting DevOps from the Ops side
The key to presenting solutions is always to identify problems first; if the team doesn't feel like you're solving any problems, then they're going to dismiss what you're suggesting.  The specific problems your Ops team is facing we don't know, but there are a number of common ones:


Getting non-actionable alerts
Spending lots of time in toil
Version upgrades are a pain
Deployments are a pain
No visibility into what the apps are doing


and so on.  Once you know what problems they're having, then you can target solutions that fix those.


  The main subjective problem seems to be that they think real bad about developers.


Cultural changes are incredibly difficult to make (usually the easiest way to is hire people with the philosophies you want and gradually prune off the old people).  But embedding operations engineers with developers can help this one immensely.  I've worked in several small companies where there was just one engineering team (and I happened to work primarily on ops work), and so this idea comes very naturally to me, but for people who have been working solely on an operations team with little contact with developers for a long time, it can be a difficult adjustment.  But move your desk to be with them, participate in their chat channels, eat lunch with them - this all helps both ops and devs realize that the other side are actually humans.  This also provides better opportunities for ops to use their expertise to solve problems for devs that otherwise wouldn't've surfaced (say, they're trying to do something and you provide a quick shell script that solves it much faster than the manual way they were going with), and that builds trust and emotional budget that you can spend when you need something from them.