Smoke testing infra: что ломается сразу после развёртывания
Развёртывание завершается с кодом ноль, а через десять минут часть сервисов не отвечает — сценарий знакомый. Инфраструктура как код описывает желаемое состояние, но не подтверждает, что оно достигнуто: модуль создал балансировщик, а правило маршрутизации не приехало, потому что переменная оказалась пустой.
За этим стоят три повторяющиеся причины. Неполное окружение — часть секретов, сертификатов и параметров подключения осталась от предыдущей среды или не переопределилась. Оборванные связи — сервис поднялся, но не видит базу, брокер или кэш, потому что группа безопасности или DNS-запись не обновились. Не выданные права — роль создана, а политика доступа к хранилищу или реестру образов к ней не привязана.
Отдельная категория — проверка конфигурации, которая нигде не запускается как самостоятельный шаг. Модули применяются успешно, но итог никто не сверяет с ожидаемым: открыты ли нужные порты, отвечает ли эндпоинт готовности, применились ли миграции, доступны ли зависимые сервисы по сети. Ошибка всплывает уже у пользователя, и время до диагностики измеряется не минутами, а часами переписки между командами.
Smoke testing infra закрывает именно этот разрыв. Короткий набор проверок после развёртывания за минуты отделяет «выкатили» от «работает»: доступность узлов, связность между сервисами, права на операции, целостность конфигурации. Проверка идёт против реально поднятого окружения, а не против описания в репозитории, поэтому ловит расхождение между задуманным и фактическим состоянием.
Дальше разбираем, как такая проверка встраивается в выпуск, что именно в неё включать и как настроить автоматический откат, когда она падает.
Smoke testing окружения: что даёт автоматизация проверок
Смоук-проверки окружения — короткий набор проверок сразу после провижининга: доступность узлов, разрешение имён, отклик балансировщика, запись в хранилище, прохождение трафика от внешнего адреса до приложения. Набор идёт минуты и ловит поломку до того, как в среду попадёт первый пользователь.
Автоматизация проверок сокращает время выпуска не «ускорением» как таковым, а снятием ручной приёмки. Инженер больше не обходит сервисы по списку — проверки идут параллельно, а результат с вердиктом пишется в журнал сборки. Выпуск перестаёт ждать человека и переноситься на следующий день.
Большая часть аварийных откатов — не про плохой код, а про неготовое окружение: неприменённая миграция схемы, отсутствующий секрет, незакрытое правило сети. Смоук-набор проверяет именно эти инварианты и переводит откат из «заметили на рабочем контуре» в «упало на проверке». Доля аварийных откатов падает потому, что часть изменений не доходит до выпуска.
Простой сервиса складывается из времени обнаружения и времени восстановления, и автоматизация сжимает первое до момента провижининга. Когда инфраструктура описана декларативно в Terraform, окружение воспроизводится повторным применением описания, а не ручной сборкой по памяти — длительность простоя перестаёт зависеть от того, кто дежурит.
Уходит и целый класс отказов, связанный с расхождением сред: проверки на промежуточном и целевом контуре показывают разницу в настройках до выпуска, а не через неделю после.
Варианты проверок: ручной чек-лист, скрипты, непрерывный контроль
Проверка после развёртывания отвечает на один вопрос: среда работает в том виде, в котором её отдали. Варианты отличаются не глубиной, а тем, кто запускает проверку, когда она срабатывает и сколько усилий требует на поддержку. Сравниваем их без навязывания одного подхода.
| Вариант | Когда подходит | Ограничения | Трудоёмкость |
|---|---|---|---|
| Ручной чек-лист | Новые типы сред и проверки, где нужно суждение: права доступа, поведение внешних систем | Шаги пропускают в спешке, результат не воспроизводится, история не сохраняется | Низкая на старте, растёт с числом сред |
| Скрипты проверок | Регулярные развёртывания однотипных стендов, повторяемое ядро проверок | Ломаются при изменении среды, покрывают только заранее описанные сценарии | Средняя, нужен владелец |
| Непрерывный контроль | Долгоживущие среды, где важно заметить деградацию между релизами | Подтверждает состояние, но не корректность нового релиза; нужны пороги и канал оповещений | Растёт с числом метрик |
На практике варианты не конкурируют, а дополняют друг друга: скрипты закрывают повторяемое ядро, чек-лист остаётся на то, что требует суждения, непрерывный контроль дежурит между релизами. Главное ограничение — устаревание: проверки, привязанные к конкретной топологии, перестают быть верными после первого же изменения среды, поэтому их ревизия входит в регламент. Выбор определяется частотой развёртываний и числом сред: чем их больше, тем раньше ручной чек-лист перестаёт масштабироваться.
Этапы внедрения: от аудита окружения до передачи регламентов
Окружение после провижининга формально готово, но до первого деплоя никто не проверяет, отвечают ли сервисы, применяются ли миграции и переживает ли стенд перезапуск узла. Работы выстраиваем так, чтобы проверки появлялись раньше первого релиза, а ложные срабатывания отлавливались на копии, а не на боевом контуре.
- Аудит окружения — инвентаризация сервисов, связей между ними, портов и внешних интеграций. На выходе карта того, что имеет смысл проверять, и список уже случавшихся отказов.
- Схема проверок — сценарии делим на быстрые и глубокие: связность, доступность сервисов, чтение и запись в хранилища, миграции, восстановление после перезапуска узла. Для каждого фиксируем критерий «пройдено».
- Настройка проверок — переносим схему в существующую автоматизацию и привязываем к событиям провижининга. Проверки не заменяют мониторинг: они отвечают на вопрос, можно ли передавать окружение дальше.
- Прогон на стенде-двойнике — разворачиваем копию боевой топологии, замеряем полное время прогона и поведение при падении узла. Здесь же подбираем предельное время ожидания ответа и число повторов.
- Отработка ложных срабатываний — отделяем деградацию от шума: неустоявшиеся сервисы, гонки при старте, временная недоступность внешних зависимостей. Ориентир — ноль красных прогонов на здоровом окружении.
- Передача регламентов — описываем действия при падении проверки, владельца каждого сценария и порядок расширения набора при добавлении новых сервисов.
Наборы проверок, схемы окружений и регламенты выпуска
Проверки хранятся не в переписке, а в репозитории рядом с описанием инфраструктуры. Наборы запускаются сразу после провижининга: вручную при разборе сбоя и автоматически в конвейере выпуска — как обязательный шлюз перед передачей стенда командам разработки.
Каждый элемент поставки описан в документации по проверкам: что именно проверяется, какое состояние считается нормой, что делать при расхождении и к кому идти за правами. Наборы версионируются вместе со схемами окружений — при изменении состава узлов видно, какие проверки устарели, а откат правил не ломает уже работающие стенды.
- Наборы проверок базового уровня: доступность узлов, разрешение имён, отклик балансировщика, готовность хранилища.
- Проверки прикладного слоя: отклик сервисов, очереди сообщений, права сервисных учётных записей, доступ к секретам.
- Схемы окружений: состав узлов, сети и подсети, балансировка, связи между сервисами и внешними системами.
- Регламент выпуска: шаги от провижининга до передачи в эксплуатацию, точки остановки и критерии готовности стенда.
- Правила доступа: разграничение ролей инженеров и сервисных записей, порядок выдачи и отзыва прав, аудит действий.
- Документация по проверкам: назначение набора, ожидаемые результаты, разбор типовых расхождений, порядок действий при сбое.
- Версионирование проверок: история изменений, привязка к версии схемы окружения, пометки об устаревших наборах.
Кейс: сократили долю аварийных выпусков после развёртывания
Точка отсчёта
Развёртывание в кластер Kubernetes завершалось зелёным статусом конвейера, но не означало, что сервис действительно работает: 18% выпусков откатывали в первые часы. Причины повторялись — непринятая миграция схемы, недоступная зависимость, неверный секрет в конфигурации. Диагностика занимала от 40 до 60 минут: инженер вручную сверял события кластера, логи и переменные окружения, а в ночных выпусках проверки шли по сокращённому списку.
Что изменили и что получили
Проверки стали обязательным шагом после провижининга и до переключения трафика: доступность эндпоинтов, готовность подов, ответы сервисов-зависимостей, применение миграций, права сервисных учёток. Прогон занимает 90–120 секунд, при падении трафик остаётся на предыдущем релизе — откат перестал быть ручной операцией. Ложные срабатывания отсекаем ожиданием готовности пода в течение заданного времени, а не падением на первом запросе.
Доля откатов снизилась с 18% до 3%, время восстановления — с 50 минут до 7. Аварийные выпуски вне регламентного окна сократились почти втрое: причина сбоя видна в отчёте прогона, а не восстанавливается по логам постфактум. Набор проверок версионируется вместе с инфраструктурным кодом, поэтому новый сервис получает их при добавлении, а не после первого инцидента.
Чем смоук-проверки отличаются от полного регресса окружения?
Смоук-проверка отвечает на один вопрос: можно ли пускать трафик в это окружение прямо сейчас. Охват — 15-25 проверок, которые проходят за минуты: поднялся ли балансировщик, отвечает ли приложение, доступны ли база, очереди, DNS и сертификаты, проходит ли вход и создание тестовой сущности насквозь. Всё остальное для неё шум — она не ищет ошибки в бизнес-логике, она подтверждает жизнеспособность.
Полный регресс проверяет поведение: сотни сценариев по всем значимым веткам, включая редкие сочетания ролей, прав и состояний данных. Он идёт часами, требует подготовленного набора данных и стабильной среды, а его результат — вердикт «функциональность не сломана», а не «окружение дышит».
Граница проходит по объекту проверки: смоук смотрит на инфраструктуру и связность компонентов, регресс — на прикладную логику. Первый даёт бинарный ответ за минуты, второй — детальный отчёт за часы. Если смоук начинает отвечать «всё ли работает правильно», он перестаёт быть быстрым и превращается в урезанный регресс.
Смешивать их рискованно в обе стороны. Раздутый смоук идёт десятки минут, в него проникают нестабильные сценарии, и команда привыкает выкладывать поверх красного результата. Замена регресса смоуком даёт обратный эффект: выкладка проходит зелёной, а дефекты всплывают у пользователей, потому что проверялась связность, а не поведение.
Практическое разделение простое: смоук — обязательный шлагбаум в конвейере выкладки, блокирующий переход трафика на новую версию; регресс — по расписанию или перед крупным изменением. Критерии готовности у них тоже разные, и именно поэтому их держат отдельными наборами.
Разбор сомнений: охват проверок и нестабильные срабатывания
Охват проверок задаётся не их числом, а перечнем путей отказа. После провижининга проверяем не только «узел поднялся», но и связность между сегментами, ответ балансировщика, права сервисной учётки, доступность хранилища и корректность DNS-записей. Так дефект конфигурации всплывает до первого развёртывания приложения, а не в момент, когда им уже пользуются.
Нестабильные срабатывания лечим причиной, а не игнорированием: ожидание готовности через опрос состояния вместо фиксированных пауз, отдельные повторы для «инфраструктура ещё поднимается» и для настоящей ошибки, изоляция проверок друг от друга. Тест, который иногда падает без повода, хуже отсутствующего — команда перестаёт ему верить и пропускает реальное падение.
Хватит ли охвата, если часть контуров разворачивается вручную?
Для таких участков фиксируем контрольные точки снаружи: доступность адресов, отклик сервисов, состояние очередей и расписаний. Ручные шаги выносим в регламент, чтобы при передаче было видно, где ждать расхождений.
Как отличить ложное срабатывание от настоящей аварии?
Каждая проверка пишет, что именно ждала и чего не дождалась: код ответа, целевой узел, длительность ожидания. По этому следу видно, деградация это или тест задел ещё не готовый компонент. Проверки готовности в Kubernetes строим на статусах объектов, а не на паузах.
Что с поддержкой набора проверок после передачи?
Отдаём его вместе с регламентом: какие проверки обязательны перед выкаткой, как подключить новый контур, где смотреть историю прогонов. Первое время сопровождаем сами — правим пороги и добавляем сценарии под изменения инфраструктуры, дальше набор ведёт команда заказчика.
Обсудим вашу задачу и вернёмся с планом проверок
Чтобы вернуться с оценкой и планом проверок, а не с общими словами, нам нужны от вас три вещи: описание контура (облако, собственные серверы или смешанная схема), текущий способ провижининга и список инцидентов, которые вы уже ловили руками. Если есть логи выкатки и конфигурации — приложите, этого достаточно, чтобы увидеть точки отказа без долгих расспросов.
Дальше работаем в два прохода: сначала разбираем контур и собираем перечень проверок, затем согласуем объём. Возвращаемся с пакетом:
- карта инфраструктуры с местами, где отказ проходит незамеченным вплоть до продакшена;
- состав проверок после провижининга: доступность сервисов, состояние зависимостей, корректность прав и переменных окружения, поведение при перезапуске узла;
- схема встраивания в конвейер поставки: какие проверки блокируют выкатку, какие только сигналят дежурному;
- требования к доступам и тестовым окружениям, где прогоняем проверки;
- оценка работ по этапам с разделением: что закрываем мы, что остаётся на вашей стороне;
- сроки внедрения — от согласования состава до первых прогонов на боевом контуре и передачи документации.
Опишите задачу свободной форме: какой контур, чем разворачивается, что уже ломается. Мы вернёмся с оценкой, планом проверок и сроками внедрения.
