Что происходит после нажатия кнопки Deploy: проверка, что новая версия действительно работает

Кнопка Deploy нажата. Пайплан горит зелёным. Команда выдыхает с облегчением. Но если вы думаете, что работа сделана, вас ждёт суровое пробуждение.

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

Релиз — это не финишная черта. Это момент, когда начинается настоящее тестирование.

Почему стейджинга недостаточно

Ваша команда наверняка запускала тесты перед релизом. Юнит-тесты прошли. Интеграционные тесты зелёные. Стейдж выглядит здоровым. Всё это хорошо, но недостаточно.

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

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

Начните со смоук-теста

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

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

Смоук-тесты по определению поверхностны. Вы не тестируете каждую фичу или граничный случай. Вы отвечаете на один вопрос: сработал ли деплой, или приложение сломалось сразу?

Вот простая bash-команда, которую можно выполнить сразу после деплоя для смоук-теста:

curl -f https://prod.example.com/health && echo "Smoke test passed" || echo "Smoke test failed"

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

flowchart TD A[Релиз] --> B[Смоук-тест] B -->|Пройден| C[Верификация] B -->|Провален| D[Откат] C -->|Пройдена| E[Мониторинг здоровья] C -->|Провалена| D E -->|Обнаружена аномалия| F{Серьёзность?} F -->|Незначительная| G[Хотфикс] F -->|Критическая| D E -->|Норма| H[Продолжить мониторинг] G --> E

Хороший смоук-тест занимает меньше двух минут. Если он автоматизирован, выполняется за секунды. Если делаете вручную, держите чек-лист коротким. Максимум пять-десять проверок. Всё, что дольше, — это уже верификация.

Переходите к верификации

Как только смоук-тест пройден, нужно проверить, что новая версия ведёт себя корректно. Верификация более систематична. Вы сравниваете фактическое поведение системы с ожидаемым.

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

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

Ключевое отличие от смоук-теста — глубина. Смоук-тест спрашивает: «Живо ли оно?». Верификация спрашивает: «Работает ли оно корректно?».

Следите за сигналами здоровья

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

Сигналы здоровья — это метрики, которые говорят, в порядке ли ваша система. Загрузка CPU, потребление памяти, частота запросов, частота ошибок, время ответа, утилизация пула соединений с БД, глубина очередей. Эти числа постоянно меняются по мере того, как пользователи взаимодействуют с системой.

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

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

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

Как долго нужно проверять?

Длительность пострелизной проверки зависит от изменений.

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

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

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

Когда что-то пошло не так

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

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

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

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

Практический пострелизный чек-лист

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

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

Главный вывод

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

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