Anna.Sokolov
New member
За двадцать лет в разработке я уронил продакшен в пятницу столько раз, что коллеги всерьёз предлагали повесить над моим монитором табличку с надписью «не деплоить после обеда». Поначалу я думал, что это злой рок, потом — что дело в усталости, а ещё позже понял простую вещь: пятничный сбой почти никогда не случаен. Это не мистика, а закономерный результат того, как мы устроили свои процессы. Пятница лишь проявляет слабые места, которые всю неделю тихо ждали своего часа. Ниже семь причин, которые я выловил в своей практике, и то, что реально помогло их закрыть.
Первая причина — релизы «под занавес», приуроченные к закрытию спринта. Мы годами тащили в пятницу всё, что не успели, и получали идеальный шторм: минимум людей онлайн, максимум изменений за раз. Вторая причина растёт из первой — уставшие и рассеянные глаза. В четверг ревью проходит вдумчиво, а в пятницу вечером коллега одобряет pull request за сорок секунд, потому что ему тоже хочется домой. Усталость не делает людей глупее, но делает их быстрее и менее внимательными, а в CI/CD цена такой скорости измеряется в инцидентах.
Третья причина, которую я недооценивал дольше всего, — миграции базы данных без обратной совместимости. Пока код откатывается за минуту, схема остаётся изменённой, и вы получаете классику: новая версия не работает, старая уже тоже. Четвёртая причина — тесты, которые светятся зелёным, ничего при этом не проверяя. Пара ретраев, скрывающая флаки, закомментированный кейс, тест, который ходит в мок вместо реального сервиса, — и конвейер превращается в ритуал успокоения. Я сам однажды полгода жил с зелёной сборкой, которая ловила ровно ноль реальных проблем.
Пятая причина — дрейф конфигурации и секретов. Стенды живут своей жизнью, кто-то поправил переменную прямо на сервере, срок жизни токена истёк, а пароль лежит в трёх местах и везде разный. Конвейер ломается не потому, что код плохой, а потому, что окружение перестало совпадать с описанием. Здесь очень помогает жёсткое правило: любые изменения только через репозиторий, а ручные правки на машинах приравниваются к инциденту.
Шестая причина — внешний мир, который вы не контролируете. Обновился базовый образ, поменял поведение облачный провайдер, закончилась квота, поднялась цена на минуты сборки, отвалился пакетный реестр. В пятницу эти вещи бьют больнее всего, потому что поддержка на той стороне уже спит в другом часовом поясе. Седьмая причина, и самая обидная, — отсутствие плана отката. «Мы никогда не откатывались» звучит гордо ровно до первого раза. Если вы не репетировали откат, значит, у вас нет отката, есть только надежда.
Что я сделал у себя и что советую вам. Во-первых, ввёл окно заморозки: в пятницу после обеда деплои только по аварийной процедуре с явным подтверждением от дежурного. Во-вторых, перешёл на флаги функций, чтобы выкатка кода и включение поведения стали разными событиями. В-третьих, настроил канареечный выпуск на малой доле трафика и обязательный автоматический откат по метрикам ошибок. В-четвёртых, запретил ломающие миграции: сначала добавляем и заполняем, потом переключаем, потом удаляем. И наконец, закрыл дрейф — все стенды собираются из одного описания, а секреты живут в хранилище.
Отдельно скажу про наблюдаемость и людей. Скучный, предсказуемый конвейер — это не тот, где ничего не падает, а тот, где падение заметно за минуты и лечится одной кнопкой. Метрики, логи, трейсы и алерты, которые не кричат по любому поводу, стоят дешевле любого героизма в субботу утром. И ещё: дежурство должно быть ротацией, а не судьбой одного энтузиаста, иначе выгорание придёт раньше, чем стабильность.
За годы я пришёл к простой мысли: пятница — не враг, а честный экзамен. Если ваш процесс держится на внимательности уставших людей, он обязательно посыпется, вопрос лишь в дате. А если релиз — это рутина, покрытая тестами, флагами и кнопкой отката, то пятничный деплой становится таким же скучным, как вторник. У меня после всех этих изменений пятницы перестали пугать, и это, пожалуй, лучшая оценка проделанной работы. А что чаще всего ломается у вас по вечерам и какой приём спас вам больше всего нервов? Делитесь историями в комментариях, у вас наверняка есть чему поучиться.
Первая причина — релизы «под занавес», приуроченные к закрытию спринта. Мы годами тащили в пятницу всё, что не успели, и получали идеальный шторм: минимум людей онлайн, максимум изменений за раз. Вторая причина растёт из первой — уставшие и рассеянные глаза. В четверг ревью проходит вдумчиво, а в пятницу вечером коллега одобряет pull request за сорок секунд, потому что ему тоже хочется домой. Усталость не делает людей глупее, но делает их быстрее и менее внимательными, а в CI/CD цена такой скорости измеряется в инцидентах.
Третья причина, которую я недооценивал дольше всего, — миграции базы данных без обратной совместимости. Пока код откатывается за минуту, схема остаётся изменённой, и вы получаете классику: новая версия не работает, старая уже тоже. Четвёртая причина — тесты, которые светятся зелёным, ничего при этом не проверяя. Пара ретраев, скрывающая флаки, закомментированный кейс, тест, который ходит в мок вместо реального сервиса, — и конвейер превращается в ритуал успокоения. Я сам однажды полгода жил с зелёной сборкой, которая ловила ровно ноль реальных проблем.
Пятая причина — дрейф конфигурации и секретов. Стенды живут своей жизнью, кто-то поправил переменную прямо на сервере, срок жизни токена истёк, а пароль лежит в трёх местах и везде разный. Конвейер ломается не потому, что код плохой, а потому, что окружение перестало совпадать с описанием. Здесь очень помогает жёсткое правило: любые изменения только через репозиторий, а ручные правки на машинах приравниваются к инциденту.
Шестая причина — внешний мир, который вы не контролируете. Обновился базовый образ, поменял поведение облачный провайдер, закончилась квота, поднялась цена на минуты сборки, отвалился пакетный реестр. В пятницу эти вещи бьют больнее всего, потому что поддержка на той стороне уже спит в другом часовом поясе. Седьмая причина, и самая обидная, — отсутствие плана отката. «Мы никогда не откатывались» звучит гордо ровно до первого раза. Если вы не репетировали откат, значит, у вас нет отката, есть только надежда.
Что я сделал у себя и что советую вам. Во-первых, ввёл окно заморозки: в пятницу после обеда деплои только по аварийной процедуре с явным подтверждением от дежурного. Во-вторых, перешёл на флаги функций, чтобы выкатка кода и включение поведения стали разными событиями. В-третьих, настроил канареечный выпуск на малой доле трафика и обязательный автоматический откат по метрикам ошибок. В-четвёртых, запретил ломающие миграции: сначала добавляем и заполняем, потом переключаем, потом удаляем. И наконец, закрыл дрейф — все стенды собираются из одного описания, а секреты живут в хранилище.
Отдельно скажу про наблюдаемость и людей. Скучный, предсказуемый конвейер — это не тот, где ничего не падает, а тот, где падение заметно за минуты и лечится одной кнопкой. Метрики, логи, трейсы и алерты, которые не кричат по любому поводу, стоят дешевле любого героизма в субботу утром. И ещё: дежурство должно быть ротацией, а не судьбой одного энтузиаста, иначе выгорание придёт раньше, чем стабильность.
За годы я пришёл к простой мысли: пятница — не враг, а честный экзамен. Если ваш процесс держится на внимательности уставших людей, он обязательно посыпется, вопрос лишь в дате. А если релиз — это рутина, покрытая тестами, флагами и кнопкой отката, то пятничный деплой становится таким же скучным, как вторник. У меня после всех этих изменений пятницы перестали пугать, и это, пожалуй, лучшая оценка проделанной работы. А что чаще всего ломается у вас по вечерам и какой приём спас вам больше всего нервов? Делитесь историями в комментариях, у вас наверняка есть чему поучиться.