>если в совсем разные - то и прекрасно, конечно. А если это просто разные уровни в одном и том же сервисе - то как вы потом разбираетесь "кто сломал прод?!"

Как правило в подавляющем большинстве мне приходится поддерживать микро-сервисные проекты, потому там да, бывает хаоос еще тот, но обычно это длится до того, пока втягивается или растет новоиспеченный тимлид ), который и будет отвественным за свою пачку микросервисов, деплой  и т.п. Чем дольше выделенная команда занимается сопровождением и доработкой этих сервисов, тем лучше и прозрачней для конечных кастомеров происходят деплоии. Имею ввиду, что отвественные люди уже знают большиство нюансов и если они ничего не понимают из мира Operators, то уже сами просто что то нащупали )). Ну а так да, микросервисы - это хаоос еще тот! Конечно никто не отменял выкатку по blue-green, но часто люди ленятся и после получения от QA и руководства добра выкатывать в прод, могут и увалить что нить )). Вот она правда жизни всяких новых CI, за это насколько я понял, часто и любят Jenkins, что у него все этапы сборки можно спрятать и делегировать только одной команде админов, отвественных за это. Но опять же, обычно чистым разработчикам лень лезть в yaml и править его или они банально боятся все сломать и это делает только их тимлид, ничего не ломая при этом )). В общем, это уже опять же больше к опыту работы в команде относится, чем к технологиям.

При пуше на централизованный git сервер всегда автоматом запускаются юнит тесты, сборка и после выливки в один из stage, могут еще и интеграционные тесты выполнится, если разрабы озаботились и покрыли свои сервисы ими. Если же на каком то этапе сборка и тесты свалились, то автор коммита автоматически получает email с строчкой, на которой упало и может пофиксить. Если CI внедрили уже давненько, то работает like a charm, ну и если что то сломалось, то могут подправить и самостоятельно, даже без привлечения человека, который изначально настраивал и интрегрировал все.

Кроме этого, как правило, все строится на обычном git flow и все новые фичи или фиксы мерджатся из своих отдельных git веток, потому выливание пачки комитов не получается такой болью при реверте, потому что ревертится сразу целый MR, ну и также всегда обычно есть еще и rollback на проде, который откатит на пред версию container image.

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

У меня последней по моему была 8.2 фря и после уже массово все хосты, которые еще не были на лине, перевели на последний. Да, есть такое, вспоминаю с улыбкой, когда после очередной сборки и обновдления ядра и мира, получаешь систему как то странно работающей, после чего идешь в списки раасылок или на форум и обнаруживаешь, что тебе надо вот этот магический патч, после применения и сборки которого все взлетает. Хорошо, когда был свой iLo или iDrac, если же нет то приходилось тероризировать саппорт дата-центров )). Дааа, были же времена, сейчас многое в облаках и подход во многом уже изменился.

PS: По контейнерам могу подитожить к тому, что оно обычно надо командам разрабатывающим какой то софт, а максимальная интеграции тебя как devops в эту команду и подразумевает реализовывать хотелки всех. Со временем и сам уже стаешь мыслить как разработчик с таким хорошим бекграундом админской деятельности, мы живем в интересное время, время разрушения стериотипов и это происходит повсеместно во многих зарубежных компаниях ))).