You can just add an ops guy with minimal coding to a dev team and it works wonders. Ops guy does the ops stuff, writes the shell scrips and consults with the devs on how to build what they need to build.
The ops guy has an opportunity to level up his coding since the devs are doing code reviews for him and devs have an opportunity level up their ops knowledge because they are working with someone who understands what hand how platform should be built.
I think it's great to "bring" knowledge to devs in this model. But not commit to individual wishes for features and implement them willy illy. The "ops guy" needs a team too, preferably to build a company shared platform that suits the large majority. This only goes of course when you either hit scale or are a large company. When smaller it's perfectly fine to unload unwanted things to one or two people.
I do very strongly believe in "you build it you run it". Keeping servers up is different than keeping your application up. I think a dev should know what health checks/probes are, what a good period time they need for their application. It's the "ops guy"'s job to make the dev guys job as easy as possible and bring expertise and knowledge when needed
The ops guy has an opportunity to level up his coding since the devs are doing code reviews for him and devs have an opportunity level up their ops knowledge because they are working with someone who understands what hand how platform should be built.