Your comment on SRE -> server janitor is interesting. Especially in the land of DevOps. Companies are looking for ways out, to have people do multiple things and not necessarily acknowledge complexity, experience when things go sideways, etc.
Being able to get things to run smoothly, having the background to know when X happens and where to look, being able to plan and intelligently navigate future capacity, etc. is incredibly important. The ops roles that used to exist, places like Google keep them, but a lot of companies do not.
If you need a dog crap collector, sell the job as a poop scooper, not a pre-compost collections technician.
I once had a "software engineering" gig where I found a way to reduce the labor of the tasks being asked of me by a factor of N (where N equaled their number of clients, which was around 10) for very little work (would've paid for itself with one, possibly two, of the six or so tasks they gave to me my first week). I was told not to do it, because those were client-billable hours when being done per client, and not when theybwere being done to help all clients.
I stayed their a very small number of days after hearing that. Point is, there are businesses that value operations work more than engineering, and that they should not.
http://multithreaded.stitchfix.com/blog/2016/03/16/engineers...
In it the difference is erased and people are reorganized in a, I think, more productive way.
Even after SRE takes over operations of a service, developers remain closely involved, and in many cases have their own pager rotation for "something's really broken, SRE has stopped the user-visible bleeding, but we need a code owner to jump in and help solve the root issue."
As a developer, that is a service I greatly value, and greatly respect those who have that knowledge and experience.
Actually, dont understand how it could be separate people either.