В компании есть Kubernetes, GitLab с пайплайнами и стена дашбордов в Grafana. А деплоить всё равно страшно — по пятницам нельзя, релиз согласовывают в личке, о падении прода первым сообщает клиент. Если картинка знакомая, то у меня плохие новости в формате чек-листа. Ниже десять симптомов карго-культа с проверочными вопросами — посчитайте, сколько наберёт ваш прод!
Откуда термин и почему это именно про нас
Во время Второй мировой армия США строила аэродромы на островах Меланезии. Вместе с самолётами прибывал груз (тушёнка, инструменты и т. д.). Часть перепадала местным жителям. Потом война кончилась, самолёты улетели. Островитяне сделали логичный вывод — дело в аэродромах! Они выложили копии взлётных полос, поставили вышки из бамбука, вырезали наушники из половинок кокоса и стали ждать. Форму скопировали один в один. Самолёты не прилетели.
В инженерный обиход слово протащил Фейнман в 1974-м — он выступил в Калтехе с речьюпро карго-культ в науке - про работы, у которых есть все внешние признаки исследования, кроме одного — честной проверки самого себя.
DevOps, по моим наблюдениям, болеет карго-культом тяжелее других инженерных областей и у этого есть механика. Практики DevOps видимы — кластер можно показать на демо, дашборд повесить на телевизор в опенспейсе. А смысл невидим, сколько времени вы восстанавливаетесь после сбоя и во что обходится ошибка, на телек не повесишь. Когда форма фотогенична, а содержание нет, копироваться будет форма.
Добавьте сюда рынок, которому выгодно продавать всякие «трансформации» и инструменты, и инженеров, которым нужен кубер в резюме — получается ну очень питательная среда. Про кубер в резюме говорю без осуждения, сам однажды поднимал кластер именно за этим. Резюме, кстати, сработало.
Дальше чек-лист. Каждый пункт устроен одинаково: как выглядит, чем болит, какой вопрос задать. На вопросы нельзя ответить «ну, у нас процессы налажены», только фактом!
1. Kubernetes, в котором нечему масштабироваться
Как выглядит. Кластер из трёх нод. Внутри монолит в одном экземпляре, Redis и почтовый воркер. Кластер застрял на версии 1.27, апгрейдить страшно, откладывают третий квартал подряд. Обслуживают полтора инженера: один на полную, второй подхватывает «когда Дима в отпуске».
Чем болит. Платите дважды — за инфраструктуру и за экспертизу. Взамен — ничего из того, ради чего K8s существует. Самовосстановление и плотная утилизация раскрываются, когда сервисов десятки и они живут в нескольких экземплярах. Зато сертификаты, апгрейды кластера и внезапно осиротевшие поды приезжают сразу, в базовой комплектации!
Вопрос. Что сломается, если завтра переехать на docker-compose и systemd? Если ответ «ничего, станет проще» — у вас не оркестратор, а аквариум. Красивый, дорогой, требует ухода (возражение «держим на вырост» разберём ниже, оно честнее, чем кажется).
2. Микросервисы, которые деплоятся только вместе
Как выглядит. Тридцать репозиториев. Релизный трейн по четвергам. Таблица совместимости версий в Confluence и релиз-менеджер с лицом человека, который знает, чем всё закончится.
Чем болит. Вы оплатили полный ценник распределённой системы (сетевые таймауты, трассировка, согласованность данных), а главную выгоду — независимые деплои — оставили в магазине. Распределённый монолит дороже обычного, обычный хотя бы падал целиком и предсказуемо.
Вопрос. Когда команда последний раз выкатывала свой сервис одна, без общего окна и созвона на восемь человек?
UPD 03.08, из комментариев: @shteyner предложил проверку точнее моей: можете ли вы безболезненно выкатить багфикс одного сервиса в любой момент недели? Если да - деплои действительно независимые. Формулировка лучше тем, что проверяется не воспоминанием, а ближайшим же багфиксом.
3. «У нас DevOps — мы наняли девопса!»
Как выглядит. Открыли вакансию «DevOps-инженер», наняли человека, выдохнули — трансформация завершена! Стена между разработкой и эксплуатацией стоит где стояла, просто теперь у стены появился штатный ответственный.
Чем болит. Один человек становится бутылочным горлышком всех изменений. Разработчики по-прежнему перебрасывают релизы через стену, только теперь есть кому писать в личку «глянь плиз». Бас-фактор схлопывается в единицу, и когда человек уходит, «культура» уходит вместе с ним в другую компанию, на зарплату побольше.
Вопрос. Если ваш девопс уедет на три недели без ноутбука — что остановится? Составьте список и перечитайте: вот это вы и называете словом DevOps :)
4. Зелёный пайплайн, которому никто не верит
Как выглядит. CI формально есть. Но релизную сборку «на всякий случай» делают руками, флапающие тесты перезапускают до зелёного, а в конфиге годами живёт что-то такое:
integration-tests: script: ./run-integration.sh retry: 2 allow_failure: true # мигает с марта, разберёмся
Чем болит. Пайплайн, которому не доверяют это декорация с побочным эффектом, настоящие поломки тонут в привычном красном. Каждый релиз снова требует ручной экспертизы. Скорость потеряли, уверенность не купили :/
Вопрос. Готовы выкатить в прод ровно тот артефакт, который собрал пайплайн не пересобирая «начисто» и не открывая руками?
5. Terraform в репозитории, правки в консоли
Как выглядит. В репозитории аккуратный Terraform с модулями. В реальности лимиты во время последнего инцидента подняли прямо в консоли облака (два часа ночи, всем было насрать не до IaC), и теперь terraform plan показывает 47 изменений, применять которые никто не решается.
Чем болит. Это хуже, чем отсутствие IaC. Без него вы хотя бы знали, что живёте руками. Теперь у вас ложная уверенность в воспроизводимости плюс apply, работающий как рулетка: никто не знает, что именно он снесёт.
Вопрос. Когда terraform plan в последний раз был пустым? «Почти пустой» не считается.
6. Сто процентов покрытия при падающем проде
Как выглядит. Порог в CI — coverage не ниже 85% (в квартальной презентации это уже «почти стопроцентное покрытие»). Порог держится, отчёты красивые. Прод при этом падает от миграции, забытого конфига и кончившегося диска, ну т. е. вещей, которые юнит-тестами не ловятся в принципе.
Чем болит. Классический Гудхарт (закон/принцип Гудхарта — утверждение, гласящее «когда мера становится целью, она перестает быть хорошей мерой»): метрика, ставшая целью, перестаёт измерять. Появляются тесты ради процента на геттеры, на конструкторы, с моками всего живого. Сопровождать их дорого, ловят они пустоту.
Вопрос. Возьмите последние десять инцидентов. Сколько из них поймал бы хоть один из ваших тестов? Я проделывал это упражнение в двух командах: счёт был 0:10 и 1:10.
7. Канал #alerts на мьюте
Как выглядит. Двести с лишним сообщений в сутки. Замьючен у всех, включая дежурного (хе-хе). О проблеме узнают когда пишет клиент — у него-то канал не замьючен, у него платёж не проходит (ха-ха).
Чем болит. Чем больше оповещений, тем позже вы узнаёте о реальной проблеме. Старое доброе правило: алерт или событие, требующее действия человека. Остальное — метрики, им место на графиках.
Вопрос. Сколько алертов за последнюю неделю закончились чьим-то действием? Если меньше одного из десяти, то канал давно дрессирует команду на «красное можно не смотреть».
8. Вечное ретро
Как выглядит. Раз в две недели стикеры, «что было хорошо», экшон-айтемы… Которые кочуют из ретро в ретро, как чемодан без ручки. Постмортемы формально blameless, но виноватого в курилке всё равно назначили.
Чем болит. Команда быстро выучивает настоящий урок — говорить бесполезно. Проблемы перестают всплывать на ретро и начинают всплывать в заявлениях об увольнении. Ритуал рефлексии без изменений — это тренажёр выученной беспомощности за счёт работодателя.
Вопрос. Назовите три вещи, которые за последний квартал изменились в работе по итогам ретро. Не «обсудили», а именно изменились.
9. Запрет пятничных деплоев как стратегия надёжности
Как выглядит. «Деплоим со вторника по четверг, до 16:00». Перед праздниками фриз на две недели (в декабре может и на три). Релизное окно бронируют, как переговорку.
Чем болит. Запрет — это признание, оформленное процессом: откат у нас ненадёжен, мониторинг молчит, деплой необратим. У DORA это воспроизводится из отчёта в отчёт: команды, которые деплоят часто и мелко, ломаются реже и чинятся быстрее тех, кто копит большие релизы. Запрет консервирует страх, а причина никуда не девается. Оговорюсь — временный мораторий как костыль на переходный период это нормально. Карго начинается, когда костыль объявили походкой.
Вопрос. Что должно стать правдой, чтобы пятничный деплой превратился в скучное событие? Список ответов это и есть ваш бэклог по надёжности.
10. Дежурный-будильник
Как выглядит. Дежурства есть как в книжке Google SRE. Только у дежурного нет прав на прод, ранбуков не существует, и вся его функция это разбудить Лёшу. Лёша не дежурный. Лёша просто всегда.
Чем болит. Время восстановления сервиса равно глубине сна одного человека. Дежурство превращается в ответственность без полномочий — с неё выгорают быстрее всего. А Лёша тем временем становится единственной точкой отказа компании, и никакой кластер тут не поможет.
Вопрос. Какую долю инцидентов дежурный закрывает сам, не эскалируя? И когда он в последний раз чинил что-то по ранбуку?
Сводная таблица для проверки своей команды
Симптом |
Контрольный вопрос |
|---|---|
K8s, в котором нечему масштабироваться |
Что сломается при переезде на docker-compose? |
Микросервисы с общим релизом |
Когда сервис уезжал в прод в одиночку? |
«Наняли девопса» |
Что встанет, если он уедет на три недели? |
Пайплайн-декорация |
Выкатите его артефакт, не пересобирая руками? |
IaC с дрейфом |
Когда plan был пустым? |
Покрытие ради процента |
Сколько из 10 инцидентов поймали бы тесты? |
Алерты в мьюте |
Сколько алертов за неделю кончились действием? |
Ретро без изменений |
Что изменилось за квартал, не «обсудили»? |
Запрет пятниц |
Что должно стать правдой, чтобы деплой в пятницу стал скучным? |
Дежурный-будильник |
Какую долю инцидентов он закрывает сам? |
Корень у всех десяти один
Все симптомы выше — одна и та же ошибка в разном гриме: практика скопирована без вопроса «зачем», из которого она родилась.
У каждой практики был момент рождения, и это всегда была чья-то боль. CI — интеграция раз в месяц превращалась в многонедельный ад. Микросервисы — сотне команд стало тесно в одном релизном цикле. Blameless-постмортемы — при поиске виноватых люди прячут информацию, и следующий инцидент чинится дольше. Цепочка всегда одна
Карго-культ — это когда цепочку берут с хвоста. Инструмент есть, практика изображается, принцип не сформулирован, а боли, возможно, никогда и не было.
Противоядие занудное, зато рабочее — восстанавливать цепочку задом наперёд для каждой заметной практики своего прода. Вот кластер — какую практику он реализует? Какой принцип за ней? Какая наша — не гуглова, а наша, родная, боль его оправдывает? Если цепочка восстановилась, отлично: теперь вы знаете, что именно защищаете. Если нет — тоже хорошо: появился готовый список кандидатов на снос. Или на признание «держим на вырост и для найма» — это тоже легитимный ответ, просто его надо произнести вслух, а не маскировать под инженерную необходимость.
Честная оговорка
Карго-культ — не синоним глупости, и текст выше не стоит читать как «вокруг идиоты». Копировать форму до понимания сути нормальная стратегия обучения: так осваивают профессию джуны, так же действует команда, у которой дедлайн ближе, чем время на разбирательство. Скопировать пайплайн соседей, когда на «понять» нет ресурса зачастую рационально.
Проблема не в копировании. Проблема — не вернуться потом с вопросом «зачем». А это уже не про людей, а про то, как в компании принимают решения: практики внедряются без хозяина, без записанного ожидаемого эффекта и без даты, когда эффект проверят. Почините три этих пункта и карго рассосётся сам, без осуждения коллег и мотивационных постеров.
Чек-лист выше — тоже модель со всеми её ограничениями. Найденный симптом значит ровно одно — у практики не восстановлена цепочка. Идём восстанавливать!
Сколько пунктов набралось у вас? И какой карго-культ вы наблюдаете прямо сейчас? Что мешает спросить «зачем» при всех? Коллекционирую образцы — несите в комментарии ))
Комментарии (29)
Helltraitor
03.08.2026 10:17По деплою в пятницу не согласен. Разработчик делает изменение, тесты проходят, деплой проходит, дальше выходные - и начинается, нужно откатить и.к. кто-то что-то не учел и по факту приложение работает, но неправильно
past
03.08.2026 10:17При высоком качестве проекта на прод выкатывается протестированный ког, в котором не может быть "не учел"
press_a_key
03.08.2026 10:17Даже при высоком качестве проекта(настоящие ирландцы передают вам привет), не всегда можно сделать тестовый контур такого же объема с теми же данными, что и прод. И часто бывает так, что на словах менеджментом постулируется высокое качество, а на деле сам требует это качество снижать в угоду скорости выкатки.
gmplays Автор
03.08.2026 10:17Про ирландцев лайк )) Мне кажется стейджи никогда не догонит прод (ни разу не видел), поэтому ставка всегда не на идеальную копию, а на умение дёшево ошибаться в самом проде (канарейка, фича флаги, откат кнопкой). А менеджмент, который на словах за качество, а руками просит "побыстрее" это ровно "система принятия решений" из последнего раздела - пока за скорость и за надёжность отвечают разные люди, побеждать будет скорость.
past
03.08.2026 10:17Не очень понял про ирландцев, но замечу, что менеджмент не должен решать инженерные задачи
gmplays Автор
03.08.2026 10:17Ирландцы это "no true Scotsman": любой контрпример объявляется ненастоящим. В нашем случае - "при высоком качестве не бывает "не учёл" - а как только "не учёл" случился, значит, качество было невысоким. Проверить такое утверждение нечем, оно всегда право.
Про менеджмент согласен, что не должен. Он и не решает напрямую, он не выбирает, писать ли тесты миграций и делать ли канарейку. Он выбирает, что берём в спринт. "Фича обещана клиенту, надёжность подождёт" по форме приоритет, по последствиям инженерное решение, просто принятое человеком, который за отказ не платит. Бэклог надёжности обычно не проигрывает спор - он в него не попадает.
gmplays Автор
03.08.2026 10:17Вот тут заступлюсь за оппонентов немного. "Не может быть "не учёл" не бывает кмк. Тесты снижают вероятность, но не до нуля, иначе постмортемы были бы никому не нужны. Я как "бывший SRE-шник" делаю ставку не "в проде не будет багов", а "баг в проде заметим за минуты и откатим за минуты". Это разные инженерные задачи, и вторая честнее.
gmplays Автор
03.08.2026 10:17Статья ровно про это. Если "кто-то что-то не учёл" доезжает до прода и всплывает только в выходные, вопросы не к пятнице, а почему тесты это пропустили, почему мониторинг не заорал в первый час, почему откат целое событие, например, а не кнопка. Запрет пятницы как временный костыль, пока это чинится очень разумно, в тексте так и написано. Карго начинается, когда костыль объявили решением и чинить перестали.
Lemonadier
03.08.2026 10:17Потому что все учитывать и покрывать невозможно, либо супер дорого, потому что каждый следующий тест стоит дороже предыдущего, каждый новый ранбук засоряет контекст и так далее. В конечном итоге в большом проекте не деплоить в пятницу просто получается дешевле.
По той же причине у вашего сервиса sli не 100%, и за этим никто не гонится
gmplays Автор
03.08.2026 10:17Соглашусь наполовину. Если "дешевле" результат расчёта, спора нет:, посчитанный трейд-офф эт ровно то, за что статья. Карго там, где "дешевле" никто не считал, а правило осталось. А вот аналогия с SLI, по-моему, работает в обратную сторону. SLO ниже 100% это бюджет ошибок. И весь его смысл - тратить остаток на скорость изменений, пока он не сожжён. Так что зрелая версия правила кмк звучит не "не катим в пятницу", а "не катим, когда бюджет исчерпан" в какой бы день недели это ни случилось.
sergey2212
03.08.2026 10:17Осознанный текст - написанный через жизненный опыт. Но к сожалению рынок таков что "стериотипы" подходов копируют из проекта в проект. И если ты не делаешь как все - вывод что наверное что то не так. В целом все что автор описал - встречаю повсеместно
gmplays Автор
03.08.2026 10:17Спасибо. "Встречаю повсеместно" звучит как та же выученная беспомощность из пункта про ретро, только в масштабе индустрии, когда "не как все" по умолчанию читается как "что-то не так", спрашивать "зачем" перестают раньше, чем успевают попробовать. Лечится, по моему опыту, одним - написанной страницей на вики "почему у нас иначе и что мы за это получаем". Как показывает моя практика, большинство претензий она снимает, а оставшиеся больше уже не претензии, а вкусы.
Я в индустрии десять лет с лишним лет, и это первая статья, которую сел и дописал, ровно потому что надоело встречать это "повсеместно" молча. Хочется хоть немного сделать нашу индустрию лучше. Посмотрим что из этого выйдет ))
hellosamurai
03.08.2026 10:17Касаемо деплоев в пятницу - это все, конечно, замечательно. Ну тут много интересных вопросов насчёт откатов и тп. А мы уверены, что разработчики написали все нужные тесты, тщательно протестировали миграции и их откат, точно знают как устроен прод и способны вернуть его в то первоначальное состояние? А то как обычно какой-то гений написал скрипт который пол базы данных перехреначил, а несчастный девопс должен подключиться и восстановить продовую бд из бэкапа. Тут вопрос не к карго-культу, а к тому что вы не учитываете любимое многими авось, потому никаких деплоев в пятницу. Строго в отведенное рабочее время, дабы не работать по ночам и выходным. А тем кто хочет деплоить по пятницам - желаю вечность работать по ночам и выходным, тогда наверняка дойдёт, почему изменения в продакшене всегда и везде должны производиться строго в рабочее время.
gmplays Автор
03.08.2026 10:17Про миграции спорить не буду, тут ты прав полностью, откат кода - кнопка, откат данных - операция с потерями. Поэтому у миграций свои правила: expand-contract вместо разрушающих изменений, ревью миграций строже ревью кода, восстановление из бэкапа отрепетировано, а не существует в теории.
А дальше мы согласны больше, чем выглядит. "Катить в рабочее время, чтобы не чинить ночью" это правило с названной причиной и ценой. Такие правила статья карго-культом не называет. Карго начинается этажом ниже когда "авось" из твоего же комментария признан погодным явлением и не чинится, тесты миграций никто не пишет, прод знает один человек, бэкап последний раз разворачивали в прошлой жизни. Запрет пятниц тогда работает громоотводом - молнию отводит, проводку не чинит. Статья ровно за то, чтобы называть это костылём вслух и чинить проводку.
shteyner
По поводу деплоя в пятницу вечером главный вопрос, а нормальный ли у вас проект, что он требует такие деплои?)
По поводу релиза микросервисов, 50/50. Вопрос скорее нужно так сформулировать, можете ли вы отправить безболезненно багфиксы в течение недели в любой момент.
past
Чем больше деплоев, тем лучше. Хорошо на тронный проект сам выкатывается по необходимости, даже в выходные
ProFfeSsoRr
Ну разработчики за четверг что-то написали же, почему это не зарелизить в пятницу?
shteyner
Если это что-то срочное вроде багфикса, выкатывайте, если же новая фича, дождитесь понедельника.
Понятно что если фича нужна на выходных, вроде ивента на праздники, выкатывайте. Но, если это спокойно может подождать понедельника, лучше подождать. Актуально только для небольших команд, где нет постоянной службы поддержки пользователей.
Tony-Sol
Это такой же карго-культ про которые статья. Вскрывается банальным вопросом - "а почему лучше подождать?".
Собственно, ответ на этот вопрос - это задача для sre/devops, причем скорее всего, это будет что-то вроде эпика от "на пару спринтов" до "цель на Q5"
shteyner
От неожиданных проблем никто не застрахован. Вот представь что случилась проблема, даже и небольшая, кто это править будет? Да, если у вас у компании IT отдел с техподдержкой 40-50 человек, то уже можно подумывать о постоянной возможности деплоя.
gmplays Автор
От неожиданных проблем никто не застрахован это правда, вопрос в цене реакции. "Кто это будет править" предполагает, что править надо сейчас, руками и срочно. Если откат кнопка, а не спецоперация, то "кто починит в субботу" превращается в "кто жмакнет откат", и для этого не нужен отдел на 40 человек, достаточно одного дежурного с телефоном. Дорого именно чинить руками в выходные, и вот этого маленькой команде правда лучше не планировать.
А если отката по кнопке пока нет тут я с тобой целиком согласен - не катить в пятницу разумно. Статья лишь за то, чтобы называть это честно "у нас дорогой откат, поэтому не катим" а не возводить в стратегию надёжности. Кажется, в этой точке мы уже согласны :)
Tony-Sol
Ну вот допустим Ваше " Вот представь что случилась проблема, даже и небольшая, кто это править будет?" это ответ на мой исходный вопрос "а почему лучше подождать?". Такой ответ порождает дальнейшую ветвь обсуждения - "а проблему прям нужно править?".
Что я тут имею ввиду - при деплое мы можем или собственно править - пытаться какими-нибудь костылями подпереть релиз, лишь бы он поехал, лишь бы циферка версии обновилась, либо забить = откатить.
В первом случае мы снова проваливаемся в тот же devops-cargo-cult - мы следуем каким-то практикам не потому что так лучше, а потому что мы думаем что так лучше, и пофиг на цену, а это и сломанный IaC, и "неудачный я выбрал день чтобы бросить курить"-devops (это был буквально я и мне очень не понравилось), и бутылочное горлышко в виде упомянутого выше devops, и сломанного ttm, и прочего печального.
Во втором случае мы вышли (но это не точно, скорее - наверное выходим) из порочного круга мантр "после 17 не катить"/"в пятницу не катить"/"в дождь не катить" (и это не шутка, работал я в компании в которой было не принято релизиться в дождь). НО - здесь естественно так же есть своя цена, а именно нужно потратить человекочасы на такую систему, которая способна сама себя восстанавливать к последнему рабочему состоянию.
Именно это я и имею ввиду под "это задача для sre/devops, причем скорее всего, это будет что-то вроде эпика". SRE должны находить такие узкие места и улучшать их, делать рабочие механизмы релиз-менеджмента (выкатить, откатить, уведомить как базовый минимум) вместо собирания бамбукового аэродрома "на следующей неделе фриз, потому что наш devops в отпуске в ПНД из-за той каши yaml'а, которую ему некогда разгрести, потому что у него 9000 релизов в сутки"
gmplays Автор
"Не принято релизиться в дождь" это мощно! Принято в коллекцию, которую я просил в финале, планка сходу высокая ))
По сути спорить почти не с чем, и особенно ценно, что цену второго пути ты назвал сам - система, умеющая вернуться к последнему рабочему состоянию это человекочасы, а не тумблер. Добавлю одно, из соседней ветки про миграции "сама себя восстанавливает" легко даётся коду и тяжело данным. Разрушающая миграция превращает "забить и откатить" обратно в "править". Поэтому в базовый минимум "выкатить, откатить, уведомить" я бы вписал четвёртый пункт - откат отрепетирован, включая базу. Иначе бамбуковый аэродром никуда не девается, просто переезжает из календаря фризов в ранбук, где слово "откатить" написано, но никем не проверено.
Tony-Sol
Это 100% точно да, прямо как в анекдоте про категории людей и бэкапы, мол на самом деле их не 2 "те кто делает" и "те кто уже делает", а 3 - "те кто уже проверяют что разбэкапливается"
UPD: про "не катить в дождь" забавно, что у этого была своя причина, которую впоследствии починили, но привычка дуть на воду, после того как обожглись на молоке оставалась.
gmplays Автор
Учитывая всякие Mythos сейчас в тренде уже продолжение этого "анекдота" - есть два типа людей "те, кто не занимается сесурити-патчингом" и "те, кого уже уволили" :)
gmplays Автор
Именно! Вопрос "а почему лучше подождать?" обычно вскрывает список как откат руками, мониторинг не ловит, канарейки нет и т.д.. Этот список и есть настоящий бэклог по надёжности, и да, по моему опыту он редко короче квартала.
Tony-Sol
И то при условии что других задач нет, чего почти никогда не случается потому что "релизим СРОЧНО, продукт горит!"
gmplays Автор
Ровно поэтому бэклог надёжности не выживает в формате "отдельный проект на потом" потому что "потом" не наступает, продукт горит перманентно. Работают, по моему опыту, два хода. Встроить фиксированную квоту спринта или железное "экшены постмортема идут вне очереди"; и положить рядом две цифры - час простоя в деньгах и час работы над канарейкой - разговор с бизнесом после этого другой. Пока надёжность на бумаге бесплатна, она проигрывает "горящему продукту" всегда!
gmplays Автор
Твоя формулировка про микросервисы мне нравится больше моей - "можете ли выкатить багфикс в любой момент недели без боли" - это и есть проверка независимости деплоев, короче моего абзаца. Беру!
Про "нормальный ли проект" соглашусь, пожалуй, наполовину. Тезис не в том, что в пятницу прям нужно деплоить. Симптом это когда пятница вызывает страх и запрет объявлен стратегией надёжности. Если пятничный деплой для вас скучен, но вы его не делаете, потому что незачем, это не карго, это здравый смысл :)