Что происходит после деплоя? Почему ваш пайплайн ещё не завершён

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

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

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

Три уровня пост-деплой верификации

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

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

Health Check: Живо ли приложение?

Health check — это самая базовая проверка. Она отвечает на один вопрос: работает ли сервис и отвечает ли на запросы? Обычно это выделенный эндпоинт вроде /health или /status, который возвращает HTTP-код 200, когда приложение живо.

Но вот ловушка: health check говорит вам только о том, что приложение не полностью мертво. Он не говорит, работает ли приложение корректно. Сервис может возвращать 200, одновременно отдавая повреждённые данные, медленные ответы или молча сбоя при критических операциях. Health checks необходимы, но это минимальная планка, а не финишная черта.

Smoke Test: Работает ли основная функциональность?

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

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

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

#!/bin/bash
set -euo pipefail

# Smoke test: проверяем, что эндпоинт логина возвращает 200
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" https://myapp.com/api/login)

if [ "$RESPONSE" -ne 200 ]; then
  echo "Smoke test failed: login endpoint returned $RESPONSE"
  exit 1
fi

echo "Smoke test passed: login endpoint returned 200"

Синтетический мониторинг: Соответствует ли приложение стандартам производительности?

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

Например, у вас может быть синтетическая проверка, которая измеряет время ответа для критического API-эндпоинта. Если время ответа после деплоя подскакивает выше 500 мс, пайплайн должен зафиксировать это, даже если эндпоинт возвращает корректные данные. Синтетический мониторинг ловит тот тип деградации, который пропускают health checks и smoke-тесты.

Что происходит при сбое верификации

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

Если вы используете canary-деплой, пайплайн может прекратить направлять трафик на новую версию и перенаправить всех пользователей обратно на старую. Если вы используете blue-green-деплой, пайплайн может переключить трафик обратно на среду, всё ещё работающую со старой версией. Конкретное действие зависит от вашей стратегии деплоя, но принцип один: остановить ущерб и восстановить сервис.

Какое бы действие вы ни предприняли, сбой должен быть задокументирован как доказательство. Ваш пайплайн должен сохранять логи health checks, smoke-тестов и синтетического мониторинга с временными метками и версией артефакта. Эти доказательства становятся критически важными, когда вы позже расследуете, что пошло не так. Без них вы гадаете.

Почему команды пропускают этот шаг

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

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

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

Если вы настраиваете пост-деплой верификацию впервые, вот минимальная отправная точка:

• Добавьте эндпоинт /health, который проверяет подключение к базе данных, кешу и критическим внешним зависимостям
• Напишите три-пять smoke-тестов, покрывающих самые критичные пользовательские сценарии
• Настройте хотя бы одну синтетическую проверку, измеряющую время ответа для ключевого API или страницы
• Настройте пайплайн на автоматический откат при сбое любого шага верификации
• Сохраняйте все результаты верификации с временными метками и номерами версий

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

Настоящий критерий успешного деплоя

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

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