Сообщить об ошибкеКороткий ответ
Однозначно правильного ответа нет: полный freeze снижает риск нового инцидента от релиза именно в критичный момент, но полностью останавливает возможность быстро исправить баг, найденный во время самой кампании, и может маскировать более глубокую проблему — отсутствие уверенности в безопасности собственного процесса релизов; альтернативой может быть не полный freeze, а усиленный процесс (canary, обязательный review, более конкретные критерии) без полной остановки.
Как это работает подробнее
полный freeze релизов — грубый, но простой и предсказуемый инструмент снижения риска, который легко коммуницировать всей организации ("ничего не трогаем на время кампании"); однако он не отличает безопасные изменения (например, конфигурационный фикс с низким риском) от рискованных (миграция схемы БД), и не даёт механизма для экстренного исправления critical bug, найденного именно во время замороженного периода, кроме как через "экстренное исключение", которое на практике часто становится лазейкой, обесценивающей весь freeze.
Компромисс: нужно явно обсудить с бизнесом и командой: (а) данные о реальной связи прошлых инцидентов во время кампаний с релизами именно в этот период, (б) стоимость невозможности быстро зафиксить баг во время freeze против стоимости риска от релиза, (в) готовность инвестировать в risk-based alternative (canary, усиленный review) вместо грубого freeze — решение зависит от этого контекста, а не является универсальным best practice.
Пример / кейс
Ожидаемое поведение: команда должна прийти к явному, обоснованному данными решению (полный freeze, risk-based подход или комбинация), зафиксировать критерии исключений заранее, а не изобретать их в момент кампании под давлением.
Пример кода
История инцидентов за последний год: 2 из 15 крупных инцидентов были вызваны релизами,
но ни один — во время маркетинговой кампании специфически (кампании занимают ~5% времени года).
Вопрос для обсуждения: оправдывает ли это данные полный freeze, или достаточно
усиленного review + canary только для изменений, затрагивающих компоненты кампании
(например, страницу акции и оплату)?Что использовать на практике
- Практический подход. Альтернативой может быть риск-ориентированный подход — не полный freeze, а требование дополнительного review/approval и canary-раскатки для любых изменений в критичный период, сохраняя возможность быстрых фиксов через ускоренный, но не пропущенный процесс проверки. Выбор зависит от исторической частоты инцидентов, вызванных релизами именно в пиковые периоды, зрелости CI/CD (есть ли надёжный быстрый откат) и от того, насколько дорог для бизнеса даже короткий инцидент именно в момент кампании по сравнению с обычным днём.
Подводные камни
- Частые ошибки. Вводить freeze как разовую реакцию на один неудачный инцидент без анализа, была ли причина именно в тайминге релиза или в более общей проблеме качества релизов; делать исключения из freeze неформальными и частыми, что превращает политику в фикцию, подрывающую доверие к процессу; не учитывать, что freeze сам по себе не снижает риск инцидентов, вызванных ростом нагрузки (а не релизами) во время кампании.