Что происходит после деплоя: Promote, Hold, Rollback, Roll-Forward, Pause или Disable

Деплой только что завершился. Новая версия работает в продакшене, обслуживает реальный трафик. Пайплайн зелёный, логи льются, дашборды мониторинга показывают свежие данные. И что дальше?

Именно этот момент — между деплоем и объявлением успеха — чаще всего ставит команды в тупик. Одни спешат закрыть задачу и переключиться на другое. Другие замирают, не понимая, нормальная ли это флуктуация или начало катастрофы. На самом деле завершённый деплой — это не решение, а начало выбора.

Как только начинают поступать сигналы observability, у вас есть шесть возможных путей. Каждый подходит для своей ситуации и имеет свои последствия. Знать, какой выбрать и когда, — вот что отличает команды, которые проводят деплои уверенно, от тех, кто просто надеется на лучшее.

Promote: версия хороша

Promote означает, что вы объявляете новую версию официальной продакшен-версией. Весь трафик остаётся на ней, а старую версию можно архивировать или удалить. Это тот исход, которого все ждут, но никогда не стоит торопиться с ним только потому, что пайплайн прошёл.

Вы применяете promote, когда все сигналы observability остаются в пределах ваших SLO. Уровень ошибок в норме, задержки не выросли, бюджет ошибок всё ещё здоров, а smoke-тесты в продакшене пройдены. Данные подтверждают то, что предполагал пайплайн: эта версия безопасна.

Ловушка здесь — слишком ранний promote. Зелёный пайплайн означает, что сборка и тесты прошли, но это не гарантирует корректного поведения в продакшене. Дайте новой версии достаточно времени, чтобы накопить значимые данные, прежде чем объявлять её готовой. То, что выглядит стабильным через две минуты, может проявить проблемы через десять.

Hold: пока нет уверенности

Hold означает, что новая версия продолжает работать, но вы пока не объявляете её официальной. Вы ждёте больше данных. Возможно, трафик ещё нарастает, или вы видите небольшую аномалию, которая может быть как шумом, так и началом чего-то серьёзного.

Hold — это безопасная середина. Вы не паникуете, но и не празднуете. Версия продолжает обслуживать трафик, пока вы наблюдаете за паттернами. Ключевое последствие: вы не можете запустить следующий деплой, пока этот не разрешён. Hold блокирует пайплайн, и это намеренно — он заставляет команду разобраться, прежде чем наваливать новые изменения поверх неопределённости.

Этот вариант хорошо подходит, когда у вас есть внутреннее ощущение, что что-то не так, но пока нет твёрдых доказательств. Доверяйте этому чувству. Если данные не говорят однозначно «promote», не форсируйте.

Rollback: вернуться к тому, что работало

Rollback означает откат к предыдущей стабильной версии. Вы убираете новую версию и возвращаете старую. Это ощущается как неудача, но это не так. Это контролируемое отступление из плохой ситуации.

Вы откатываетесь, когда уровень ошибок превышает SLO, бюджет ошибок сжигается быстрее ожидаемого или обнаружен критический сбой. Критерии чёткие и объективные. Если цифры говорят, что новая версия хуже старой, не колебитесь.

Загвоздка в том, что rollback работает, только если вы к нему подготовились. Механизм должен быть протестирован до аварии, а не спроектирован во время неё. Изменения базы данных, несовместимые с предыдущей версией, могут сделать откат невозможным — именно поэтому roll-forward существует как альтернатива.

Roll-Forward: исправить вперёд, а не возвращаться назад

Roll-forward означает, что вы оставляете текущую версию работать, но немедленно начинаете собирать новую версию, которая исправляет проблему. Вместо отката вы пушите фикс поверх сломанного релиза.

Этот вариант имеет смысл, когда проблема небольшая и ваша команда может быстро выпустить исправление. Это также единственный выбор, когда откат невозможен — например, если миграция базы данных изменила схему так, что старый код с ней не работает.

Roll-forward требует уверенности, что фикс действительно сработает. Если вы гадаете, можно сделать только хуже. Он также давит на команду, заставляя работать быстро, что может привести к поспешным решениям. Используйте roll-forward, когда путь ясен, а не когда надеетесь на лучшее.

Pause: остановиться и разобраться

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

Используйте pause, когда видите что-то странное, но недостаточно серьёзное для отката. Задержки немного выросли в одном регионе. Уровень ошибок подрос, но остаётся в пределах SLO. Один эндпоинт ведёт себя необычно, а всё остальное нормально.

Pause даёт вам время понять, что происходит, прежде чем принимать более серьёзное решение. Он предотвращает поспешный откат, который может оказаться ненужным, или поспешный promote, который может быть преждевременным. Цена — заблокированный пайплайн, но это малая плата по сравнению с неверным решением.

Disable: отключить сломанную часть

Disable означает, что вы деактивируете конкретную функцию или функциональность без отката всей версии. Для этого нужны feature flags или другой механизм, позволяющий включать и выключать отдельные возможности независимо.

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

Disable быстрее и безопаснее, чем rollback, когда проблема изолирована. Он также даёт команде время исправить конкретную функцию, не нарушая весь деплой. Предварительное условие — ваша архитектура должна поддерживать гранулярные переключатели, в которые стоит вложиться, если вы деплоите часто.

Как выбирать

Правильное решение зависит от трёх вещей: насколько серьезна проблема, сколько у вас осталось бюджета ошибок и как быстро ваша команда может отреагировать. Команды, у которых определены SLO и отслеживается бюджет ошибок, имеют объективную основу для этих решений. Если бюджет ошибок почти исчерпан, даже небольшая аномалия может оправдать откат. Если бюджет ошибок велик, вы можете выбрать hold или pause для дальнейшего изучения.

Следующее дерево решений сопоставляет сигналы observability с соответствующим действием:

flowchart TD A[Деплой завершён, данные мониторинга доступны?] -->|Да| B{Все сигналы в пределах SLO?} A -->|Нет| C[Подождать данных, затем переоценить] B -->|Да| D{Бюджет ошибок почти исчерпан?} B -->|Нет| E{Проблема изолирована в одной функции?} D -->|Нет| F[Promote] D -->|Да| G{Hold или Rollback?} G -->|Hold| H[Hold] G -->|Rollback| I[Rollback] E -->|Да| J[Disable] E -->|Нет| K{Можно ли безопасно откатиться?} K -->|Да| I K -->|Нет| L{Roll-forward фикс готов?} L -->|Да| M[Roll-Forward] L -->|Нет| N[Pause]

Чего стоит избегать — принятия решений на основе одной интуиции. Когда данные ясны, путь ясен. Когда данные неясны, используйте hold или pause, пока они не прояснятся.

Практический чеклист для решений после деплоя

  • Вы подождали достаточно долго, чтобы накопились значимые данные observability?
  • Все ли сигналы в пределах SLO, или есть аномалия, требующая расследования?
  • У вас есть протестированный механизм отката, или вы заблокированы изменениями базы данных?
  • Проблема изолирована в одной функции, которую можно отключить независимо?
  • У команды есть ресурсы, чтобы быстро собрать фикс, если вы выберете roll-forward?
  • Пайплайн заблокирован hold или pause, и все знают, почему?

Вывод

Деплой не завершён, когда код запущен. Он завершён, когда у вас достаточно данных, чтобы принять уверенное решение о том, что делать дальше. Шесть вариантов — promote, hold, rollback, roll-forward, pause и disable — дают вам словарь для этого решения. Используйте их осознанно, опираясь на сигналы, а не на догадки. Версия, которую вы деплоите, — не окончательный ответ. Решение, которое вы принимаете, наблюдая за её работой, — вот что действительно важно.