Автоматические Smoke Tests после деплоя: настройка и реализация в CI/CD

Smoke tests после деплоя: где ломается релиз

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

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

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

Smoke tests после деплоя — это автоматическая проверка после релиза: короткий набор обращений к ключевым путям, который прогоняется сразу после выкладки и до открытия трафика. Ниже разбираем, как это закрывается — от выбора проверок до автоматического отката релиза.

Что даёт автоматическая проверка после релиза

Автоматическая проверка релиза отвечает на один вопрос: работает ли основной пользовательский сценарий прямо сейчас. Набор из 10–20 коротких проверок бьёт по критичным путям — вход, оформление заказа, выдача каталога, постановка задачи в очередь. Полный регресс такой набор не заменяет: его задача — дать ранний сигнал и не пустить деградацию дальше по окружениям.

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

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

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

Режимы запуска дымовых проверок: сравнение вариантов

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

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

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

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

1. Аудит релизного цикла. Карта пути от коммита до промышленного контура: где остались ручные операции, как часто выходят релизы, сколько занимает возврат к предыдущей версии.
2. Схема проверок. 8–12 сценариев на вопрос «система жива»: доступность входа, авторизация, ключевая операция чтения и записи, доступность внешних зависимостей. Набор длиннее делает проверку узким местом релиза.
3. Точка запуска и блокировка. Проверки идут после развёртывания на стенд, но до переключения трафика: провал останавливает выкатку и возвращает предыдущую версию.
4. Настройка конвейера. Учётные данные тестового пользователя — в хранилище секретов, тестовые данные создаются и удаляются в рамках прогона, отчёт с логами прикладывается к сборке с меткой версии.
5. Проверка на учебном сбое. Намеренно ломаем зависимость и убеждаемся, что конвейер останавливается, откат проходит, а оповещение приходит ответственному.
6. Передача в эксплуатацию. Отдаём регламент: кто добавляет сценарий, что делать при изменении внешнего интерфейса, как разбирать ложные срабатывания, плюс обучение дежурной смены.

Что остаётся в репозитории и документации

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

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

Кейс: как сократили время обнаружения сбоя

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

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

Что изменили

Собрали smoke-набор из 14 сценариев, отвечающих на один вопрос — жив ли продукт: доступность API, сквозной заказ, оплата в тестовом контуре, доставка событий в очередь, поведение сервиса при недоступности соседа. Прогон занимает 2-3 минуты.

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

Время обнаружения сбоя сократилось до 2-4 минут вместо 40-90. Отказы класса «сервис не поднялся» и «неверная конфигурация» перестали доходить до пользователей: за месяц из нескольких десятков выпусков ни один не дожил до продакшена в нерабочем виде.

Ручная проверка перед выпуском сократилась примерно на 80% — по чек-листу проходят только релизные кандидаты. Команда стала выкатывать мельче и чаще: цена ошибки упала, а стабильность выпусков выросла.

Что делать, если деплой идёт, а проверок нет?

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

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

Технические сомнения по дымовым проверкам

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

На каком окружении запускать проверки после выката?

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

Что делать с тестовыми данными, чтобы не задеть реальные?

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

Кто поддерживает набор проверок после передачи?

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

Обсудим схему проверок для вашего релизного цикла

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

Со стороны заказчика обычно нужны:

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

Взамен возвращаемся с оценкой объёма работ и планом внедрения: какие проверки ставим на автоматический запуск после деплоя, за какое время проходит набор, на каких условиях он блокирует продвижение сборки и как запускает откат.

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