Зависит от компаний. Вообще в крупных компаниях ops и девопс это совсем разные вещи. Настраивать условные сети или опенстек девопс не будет. А вот мелкие пытаются нанять людей которые будут делать все одновременно.

Если без троллинга то ближе всего к правильному понимаю выглядит как то так

Developer - занимается разработкой
Ops - готовит инфраструктуру
DevOps - помогает разработчикам бесшовно выкатывать то что они написали на эту инфраструктуру
SRE - принимает готовый продукт на прод и дальше поддерживает его работу обеспечивая отказоустойчивость. (Именно продукта не инфраструктуры, тоже важный момент)

В целом разницы нет кому ее предоставлять внешним клиентам или внутреним. Если ты компания на 20-100 тысяч человек то внутрений клиент по всем признакам уже как внешний) Какие то люди где то заказывают инфраструктуру и используют. Поэтому условная команда инфраструктуры может уже иметь и своего SRE и своих разрабов и своих девопсов и назвать это service operations)

А какая то внешная компания может вообще не иметь OPS и разворачивать все где то на условном AWS

С появлением контейнеризации и облаков поводов для этих конфликтов и нет) Есть условный хельм чарт от разрабов и кубер от опсов. Если кубер работет стабильно. То нет ни каких причин беспокоить опсов.

Или Azure или AWS и т.д. Там опсы вообще не нужны. А если работает что то нестибильно то надо просто приложение размызывать по 2-3 зонам. Опять же опсы тут не причем. Это уже SRE должны думать как сделать так что бы если что то под приложения выпало оно продолжило работать.

SRE/бэкендер. Опсы то тут причем?

Конечно если это мелкий проект. Или DBA если крупный. ОПСы то тут причем? Они не должны кривые SQL запросы приложения править. Даже больше скажу. Они не должны иметь доступа к продовой базе. Где данные клиентов лежат и подобное