Что происходит после успешного развертывания

Лог деплоя говорит, что всё прошло успешно. Сервер запустился без ошибок. Артефакт установлен чисто. Пайплайн зеленый на всех этапах.

Но ничто из этого не говорит вам, работает ли новая версия на самом деле для пользователей.

Чистый деплой — это только фаза установки. Настоящий вопрос начинается после того, как трафик попадает на новый код. Ведет ли приложение себя так, как должно? Получают ли пользователи тот опыт, который вы задумали? Ответ вы не найдете в логах деплоя.

Разрыв между деплоем и нормальной работой

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

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

Пять индикаторов для проверки после деплоя

Уровень ошибок

Уровень ошибок — самый прямой сигнал, что что-то пошло не так. Если ваш API-сервис обычно работает с уровнем отказов 0,1 процента и вдруг после деплоя подскакивает до 5 процентов — у вас проблема.

Чтобы проверить уровень ошибок сразу после деплоя, выполните запрос к вашему метрическому эндпоинту. Например, с Prometheus:

curl -s 'http://localhost:9090/api/v1/query?query=rate(http_requests_total{status=~"5.."}[5m])'

Это возвращает частоту ошибок 5xx за последние пять минут. Сравните результат с вашим базовым уровнем до деплоя, чтобы решить, нужен ли откат.

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

Задержка

Иногда новая версия не вызывает ошибок вообще, но каждый ответ занимает больше времени. Пользователи все еще могут пользоваться приложением, но опыт ухудшается. Увеличение задержки может быть вызвано неэффективным кодом, измененными запросами к базе данных или достижением пределов серверных ресурсов.

Если задержка неуклонно растет после деплоя и не возвращается к норме, значит, в новой версии что-то потребляет больше времени на запрос, чем должно.

Насыщение

Речь о том, насколько загружены ресурсы вашего сервера. CPU, память, соединения с базой данных, дисковый ввод-вывод. Новая версия может быть прожорливой к ресурсам, и никто этого не заметит во время тестирования.

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

Здоровье зависимостей

Бэкенд-сервисы редко работают в одиночку. API-сервис зависит от баз данных, кешей и других сервисов. Воркер зависит от брокера сообщений. Когда ваша новая версия начинает обращаться к зависимостям по-другому, эти зависимости могут отвечать не так, как вы ожидаете.

Иногда проблема вообще не в вашем сервисе. Она в сервисе, который вы вызываете, и новая версия — это первый раз, когда эта зависимость используется в реальных условиях.

Бизнес-сигналы

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

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

Что делать, когда что-то пошло не так

Если индикаторы показывают, что новая версия работает некорректно, самый безопасный ответ — откат. Вернитесь к предыдущей версии, которая была стабильной.

Следующая блок-схема отображает процесс мониторинга после деплоя и решение об откате или продолжении:

flowchart TD A[Деплой зеленый] --> B{Проверить уровень ошибок} B -- ok --> C{Проверить задержку} B -- alert --> R[Откат] C -- ok --> D{Проверить насыщение} C -- alert --> R D -- ok --> E{Проверить здоровье зависимостей} D -- alert --> R E -- ok --> F{Проверить бизнес-сигналы} E -- alert --> R F -- ok --> G[Мониторинг] F -- alert --> R

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

Как автоматизировать откат, зависит от вашей стратегии деплоя:

  • Rolling update: настройте пайплайн на возврат к предыдущей версии, если уровень ошибок превышает порог.
  • Blue/green: переключите трафик обратно на старое окружение.
  • Canary: остановите канареечную версию и направьте весь трафик обратно на стабильную версию.

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

Для каждого сервиса нужны свои пороги. Критически важный API, от которого напрямую зависят пользователи, должен иметь более жесткие пороги, чем фоновый воркер, обрабатывающий пакетные задания.

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

Используйте этот чек-лист после каждого деплоя, чтобы убедиться, что новая версия работает нормально:

  • Уровень ошибок находится в ожидаемом диапазоне (сравните с базовым уровнем до деплоя)
  • Задержка не увеличилась значительно
  • Использование ресурсов сервера (CPU, память, соединения) стабильно
  • Все критические зависимости отвечают нормально
  • Бизнес-сигналы (регистрации, транзакции и т.д.) соответствуют ожидаемым паттернам
  • Порог отката определен и автоматизирован

Настоящий конец деплоя

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

Установите свои пороги, следите за индикаторами и автоматизируйте откат. Страховочная сеть сработает только если она готова до того, как она понадобится.