А при каких обстоятельствах девопс может отправляет артефакт на доработку? Я не девопс, просто интересно какую ответственность с разработчика сейчас принято перекладывать на девопса.

Ну и знакомство с практикой девопса у меня только на примере одной компании.

В идеале, конечно, кто пишет код - тот и отвечает за его работу (на проде).
В реальности, где обычно СТО - это бывший девелопер, да ещё с тех времён, когда о You build it You run it не слышали, на "девопсов" будет возложена "ответственность" (а точнее - сисадминов сделают козлами отпущения)

Если артефакт непонятно как конфигурировать, например. Там дофига параметров, и вообще не ясно какой из них за что отвечает.

Если артефакт не сможет функционировать в среде продакшена. Например, сайентисты написали сервис, который требует видюху для работы, а без видюхи работает так медленно, что лучше бы не работал вообще, и на боевых серваках видюх нет.

Если артефакт не выполняет контракты. Допустим, он использует неспецифический для боевой среды способ формирования routing key в реббите.

Если артефакт заявляется как микросервис, но при этом он stateful без ОЧЕНЬ существенной на то причины. Допустим, сайентисты сделали кластеризатор, и кластеры почему-то не в редис кладут, а в файлы рядом со скриптом.

Если артефакт не мониторится. Допустим, его логи вообще ничего не говорят о его работе.

Глобально - если артефакт создаст риски падения прода по любым возможным причинам. Потому что девопс лучше всех знает продовую среду, и может заранее предвидеть то, чего ни разраб, ни тем более сайентист, предвидеть не могут.

Исходя из этого, кстати, логично приходит заключение, что девопс должен участвовать в постановке задач разработчикам. Чтобы не приходилось отправлять артефакты на переписывание слишком часто.

Если артефакт по каким-то причинам не может быть горизонтально замасштабирован, при условии, что такие требования к проекту и к данному конкретному артефакту есть. Например, когда артефакт конкурирует за какой-то уникальный ресурс со своими соседними инстансами, и это ломает какой-то процесс.

Продовая среда даёт дофига нюансов, о которых разрабы либо не знают, либо забивают просто. И взрывы этих нюансов кто-то должен предвидеть и предотвращать по возможности.

А если код написан правильно, но при переезде на новые серваки всё начинает сыпаться, то это должны фиксить разрабы? У них спринт как бы, и они должны фичи доставлять клиентам.

цель ведь делать не фичи ради фич, а продукт. Так что если все сломалось, то решать надо тем, кто может. После уже сделать ретроспективу как этого избежать в дальнейшем.

Чем запуск кода на сервере B принципиально отличается от его запуска на сервера A? И почему при смене первого на второй девелоперы резко и магически теряют навык запуска своего кода?

Так фичи и делаются для продукта. Точнее - ради клиента. Есть техспеки, в которые вам нужно попасть. Не попали - не получите денег. Но новые фичи требуют новых мощностей. Поэтому нужно переезжать. Однако, если разрабы сами займутся переездом, то, во-первых, они зададутся логичным вопросом - а зачем нам девопс, а во-вторых - планы по запилу фич непредсказуемо съедут.

"У них спринт как бы, и они должны фичи доставлять клиентам" - вот об этом извращённом понимании я и говорил, когда упоминал "СТО из бывших девелоперов".
Это у них обычно такая абберация сознания, из чего много печальных следствий.

Принципиально не отличается, отличается в мелочах. Допустим, на сервере B другая ось. Допустим, там проц не поддерживает AVX. Допустим, это вообще переезд с железных серваков на виртуалки в опенстаке, куда железо нужно вручную маунтить.

Почему вопрос "зачем нам девопс" звучит как проблема, если на самом деле - это вершина хороших практик (NoOps)?
И почему время на запуск кода на каком-либо из серверов - "непредсказуемое"? Это-ж до какой степени хреново надо выстроить operations, чтобы не мочь предсказать деплоймент?

Это вопрос не operations, а среды.

Зачем вы допускаете такое? Ваш СТО - профнепргигоден? Ах, ну да - всё те же самые последствия дурной практики "СТО из девелоперов"

Среда разная. Среда - это то, в чём девопс шарит лучше всех остальных. Среда - причина подавляющего большинства проблем в проде.

Не надо делать разные

Существуют ли ситуации, когда невозможно сделать прод и стейдж идентичными?

Разные среды - настолько очевидный источник многих бед, что лет 10-15 назад придумали Infractructure As a Code, чтобы было одинаково

В голову не приходило, что это ответственность девопсов. У нас пока принято, что разработчики думают что им потребуется - уточняют у девопосов/админов есть ли требуемые ресурсы (а если нет, то какие альтернативы) и только после этого попадает фича в работу. А если ресурсов нет, то они согласовывается расширение/закупка с руководством. Ну и конфигурирование сервиса - так же, пока, проблема разработчика, а если что, то фичу завернет QA, если ему покажется, что описание как запускать и  тестировать не очень прозрачное или настройки запутанные.

При таком подходе, да девопсы, как и безопасники должны быть в курсе всех задач которые планируются взять в работу и они должны пройти согласование с ними. Даже если у них нет права "вето" в компании на сервис/фичу, то им время надо подготовиться к внедрению, увеличив ресурсы или установив нужные драйверы.

Спасибо за развернутый ответ.