После деплоя: что проверить, прежде чем считать задачу выполненной

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

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

Почему успеха пайплайна недостаточно

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

  • Подключение к базе данных, которое замедляется, потому что продакшен-датасет в десять раз больше стейджинга
  • Конфигурация кэша, которая отлично работает на тестовых запросах, но даёт промахи на реальных пользовательских паттернах
  • Неправильно настроенный сервер, который не заметил скрипт деплоя
  • Сторонний API, который иначе реагирует под реальной нагрузкой

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

Разница между деплоем и верификацией

Деплой — это размещение новой версии в среде. Верификация — это подтверждение того, что новая версия работает в этой среде как ожидалось.

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

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

flowchart TD A[Пайплайн зелёный] --> B[Запуск скрипта деплоя] B --> C[Артефакты загружены] C --> D[Трек деплоя завершён] D --> E{Трек верификации} E --> F[Smoke-тест] F --> G{Пройден?} G -- Нет --> H[Откат] G -- Да --> I[Проверка уровня ошибок] I --> J{В пределах нормы?} J -- Нет --> H J -- Да --> K[Проверка задержки] K --> L{В допустимых границах?} L -- Нет --> H L -- Да --> M[Проверка пропускной способности] M --> N{Ожидаемый объём?} N -- Нет --> H N -- Да --> O[Деплой завершён]

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

Начните с smoke-теста

Самый базовый шаг верификации — smoke-тест. Термин пришёл из аппаратной инженерии: когда вы впервые включаете новое устройство, вы проверяете, не пошёл ли дым. Нет дыма — значит, устройство хотя бы не загорелось.

В деплое программного обеспечения smoke-тест — это быстрая проверка, жива ли новая версия и отвечает ли она. Он отвечает на один вопрос: может ли эта версия принимать запросы и возвращать адекватные ответы?

Практический smoke-тест может включать:

Вот минимальный bash-скрипт, который запускает smoke-тест для задеплоенного эндпоинта и завершается с ненулевым кодом при ошибке:

#!/bin/bash
# smoke-test.sh - Быстрая проверка, что задеплоенная версия жива

URL="https://your-app.example.com/health"
EXPECTED_STATUS=200

HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$URL")

if [ "$HTTP_STATUS" -ne "$EXPECTED_STATUS" ]; then
    echo "Smoke-тест не пройден: ожидался статус $EXPECTED_STATUS, получен $HTTP_STATUS"
    exit 1
fi

echo "Smoke-тест пройден: $URL вернул $HTTP_STATUS"
exit 0
  • Открытие главной страницы и проверка ответа 200
  • Вызов простого API-эндпоинта и проверка структуры ответа
  • Подтверждение, что соединение с БД живо
  • Проверка, что статические файлы загружаются корректно

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

Проверьте базовые сигналы

Как только smoke-тест пройден, посмотрите на операционные сигналы системы. Это метрики, которые показывают, работает ли новая версия нормально или вызывает проблемы.

Набор сигналов зависит от того, что именно вы деплоили, но есть универсальные:

  • Уровень ошибок: процент неудачных запросов выше, чем до деплоя?
  • Задержка (latency): время ответа в допустимых пределах? Внезапный всплеск часто указывает на проблему.
  • Использование ресурсов: значительно ли изменились CPU, память или диск после деплоя?
  • Объём трафика: получает ли система ожидаемое количество запросов? Резкое падение может означать, что пользователи не могут достучаться до новой версии.

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

Главное — сделать эту проверку стандартной частью процесса деплоя, а не тем, что вы делаете, когда вспомните или когда кто-то сообщит о проблеме.

Верификация — часть деплоя

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

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

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

Разные типы изменений требуют разных проверок

Не все деплои одинаковы. Обновление приложения, миграция базы данных и изменение инфраструктуры — у каждого свои риски и свои сигналы для проверки.

Для обновления приложения основные риски связаны с обработкой запросов, корректностью ответов и интеграцией с существующими сервисами. Обычно достаточно smoke-тестов и проверки уровня ошибок.

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

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

Принцип тот же: определите, что может пойти не так для этого конкретного типа изменений, и проверьте это, прежде чем считать деплой завершённым.

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

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

  • Smoke-тест пройден: главная страница, критичные API-эндпоинты, соединение с БД
  • Уровень ошибок не выше, чем до деплоя
  • Задержка (latency) в пределах нормы
  • Использование CPU и памяти стабильно
  • В логах приложения нет необычных сообщений или ошибок
  • Если была миграция БД: статус миграции успешный, производительность запросов в норме

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

Вывод

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