А чего тут говорить.
Есть Development (в том числе и "на все руки мастера" - "full stack"), есть Operations ("поддержка инфраструктуры, пользователей, админы, ...).
Строго говоря, одни не представляют проблем других.

Очевидно, что (кроме редких случаев :)), люди из Operations на серьёзных девелоперов не тянут (скилы или уходят, если они и пришли из Dev, или ещё не набраны, если и есть потенциал).
Верно и обратное. Лет 10-15 практической #@ли с тюнингом и troubleshooting'ом СУБД (с не одной сотней настраиваемых параметров), OS, сетей, систем хранения, ... (с рабочими, не искусственными нагрузками), "набитость" руки, знание типичных проблем, не заменишь абстрактными знаниями.

Для "админов" (operations) внутренняя кухня девелоперов - чёрный ящик, из которого периодически только баговые релизы вылетают.
С другой стороны, заботы админов бывает просто не представимы девелоперами:
- хватит ли maintenance window на deploy приложения, обновления базы,
- пройдёт ли обновление online под рабочей нагрузкой с приемлемым для пользователей проседанием производительности
- тренды рабочих нагрузок и capacity planing
- ...

Был пример. Планируется конвертация внутренних данных базы. При согласовании плана обновления выясняется, что разраб ничтоже сумняшеся собирается запускать аппликуху конвертации со своего рабочего десктопа (работает предположительно пару часов). "- А что тут такого, в Dev/Test окружении не один десяток раз так запускал".
О том, что могут кабель какой перекопать (бывало) в самый интимный момент, коннекты к БД по какой-либо легитимной причине порезаться, ещё что ещё такое произойти, в конце концов, декстоп его взять и перезагрузиться, человек не подумал или не захотел подумать.
Вразумили, вынесли приложение на app сервер (где и co-location с БД прямо скажем получше).

Помимо того, что скилы/задачи у Op и Dev в целом лежат в разных плоскостях, есть ещё и явный конфликт интересов.
У разрабов, "без которых и продукта то и не было бы", главное - реализовать (ну так, чтобы без совсем уж критичных функциональных багов) новые фичи и выкинуть релиз в продуктив.
Для админов, "которые на своих плечах..." - идеальное состояние системы - выключить все серверы и уйти спать. Самое горячее время - выход в продуктив новых релизов.
Баги, приводящие к повышенной нагрузке, часто приводят к нестабильности системы. И тут начинается бодание - "у вас БД не работает", "нет, это вы сами такую #$ню только что зарелизили".

В силу различий скилов, задач, способа организации работ, Development и Operations в более-менее крупных оргнизациях практически всегда (были?) разнесены. Dev подчас может быть вообще отдан на сторону.
Из-за упомянутых различий эти отделы практически всегда являются онтагонистами. Стена, возникающая между ними (если не прямой конфликт, то просто уход одной из сторон "в несознанку") - несомненно мешает эффективной совместной работе, а это, в свою очередь, несомненно мешает бизнесу.

Кто-то "умный" придумал - а давайте просто объединим два этих отдела и повесим обязанности на одну команду, "тогда проблема антогонизма исчезнет сама собой".
Тут есть рацинальное зерно. Тесное сотрудничество разработчиков с грамотным админами - залог создания действительно качественного продукта. Только админы могут выдать грамотный фидбэк касательно продуктивной нагрузки.
Но чёрт, конечно, в деталях. Вопрос реализации (построения такой команды), универсального рецепта которой, как я понимаю, никто не дал.
Сдаётся мне, в целом DevOps - очередное маркетинговое нае....во, сходное с проблемой 2000, где, впрочем, могут погреть руки _все_ - и коучи, и консалтеры, и разрабы/админы (профилируя себя под DevOps специалистов), и даже топ менеджмент, затевая грандиозные реорганизации.

PS Ну а фулл-стэк - ну что, надо помнить, что full - на самом деле только в контексте какого-то стэка (этакий "вертикальный рынок"), и что лет 25-30 назад, когда могло казаться, что можешь быть спецом "вообще во всём IT", обуславливалось это лишь узостью кругозора.
Работодателю же, конечно, всегда хотелось, чтобы "и швец, и жнец, и на дуде игрец".
Как правило за термином скрывается умение писать и front-end, и back-end, включая умение лазить в базу. Почему нет. Для спеца же высокого класса (который может работодателя выбирать), мне кажется странным желание заниматься всем сразу.