Димові тести після деплою: де ламається реліз
Реліз вважається успішним, коли конвеєр дійшов до останнього кроку і повернув «зелений» статус. На практиці це означає лише те, що зібрався артефакт і пройшли тести на стенді.
Після перемикання трафіку сервіс може не відповідати: не піднялися залежності, не підхопився секрет, зайнятий порт. Невдале викладення при цьому формально не відкочується — вважається доставленим.
Окремий клас збоїв — розсинхронізація конфігурацій і збій оточення. Набір змінних на стенді та в робочому контурі розходиться, міграція схеми застосовується без зворотної, зовнішня залежність відповідає не тим кодом, що на прийманні.
У журналі збірки цього не видно: перевірки закінчуються раніше, ніж продукт починає обслуговувати реальні запити.
Ціна невдалого викладення — вікно недоступності, довжину якого визначає не регламент, а те, як швидко користувач напише в підтримку. Далі ручний відкат релізу під тиском, пошук останньої робочої версії та повторне викладення. Чим пізніше виявлено збій, тим менше впевненості, що попередній стан відновлено повністю.
Димові тести після деплою — це автоматична перевірка після релізу: короткий набір звернень до ключових шляхів, який проганяється одразу після викладення і до відкриття трафіку. Нижче розбираємо, як це закривається — від вибору перевірок до автоматичного відкату релізу.
Що дає автоматична перевірка після релізу
Автоматична перевірка релізу відповідає на одне питання: чи працює основний користувацький сценарій прямо зараз. Набір з 10–20 коротких перевірок б'є по критичних шляхах — вхід, оформлення замовлення, видача каталогу, постановка завдання в чергу.
Повний регрес такий набір не замінює: його завдання — дати ранній сигнал і не пустити деградацію далі по оточеннях.
Час виявлення збою падає з годин до хвилин: звіт формується в тому ж прогоні, що й викатка, тому черговий дізнається про падіння раніше першого звернення в підтримку.
Частка ручних обходів сервісів скорочується до нуля на типових релізах — замість чек-листа на тридцять пунктів інженер розбирає один крок, що впав, і його причину.
Усунений клас відмов — недоступні залежності, міграція, що не пройшла, непрогрітий кеш, конфігурація не того оточення.
Перевірка готовності оточення спирається на штатні механізми оркестратора в Kubernetes і не потребує доопрацювання застосунку: результат видно до того, як трафік піде на новий екземпляр.
Передбачуваність випуску перестає залежати від того, хто саме котить реліз: один набір перевірок, один звіт, однакова планка для тестового і робочого середовища. Рішення про відкат приймається за фактом, а не за відчуттям.
Режими запуску димових перевірок: порівняння варіантів
Режими відрізняються не глибиною, а тим, де стоїть точка прийняття рішення: до викатки на всіх вузлах або після, на частині трафіку.
Запуск перевірок у конвеєрі дає відповідь за хвилини, канареечний випуск — за час спостереження, але ловить деградацію, яку точковий набір не бачить. Нижче — реальні альтернативи, між якими обирають на старті.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручний чек-лист після випуску | Рідкісні релізи, успадкована система без тестів | Залежить від людини, повторюваність низька, про відмову дізнаються від користувачів |
| Димовий набір на критичний шлях релізу | Основний режим: вхід, оплата, ключовий сценарій | Ловить явні поломки, але не бачить часткової деградації |
| Вибіркові перевірки за зміненими сервісами | Часті дрібні випуски, монорепозиторій | Потрібна карта залежностей, інакше пов'язані модулі пропускаються |
| Канареечний випуск з автоматичним відкатом | Висока ціна помилки, є метрики і балансувальник | Довша настройка, потрібні пороги та вікно спостереження |
На практиці варіанти комбінують: обов'язковий шлюз з вибіркових перевірок за критичним шляхом релізу, потім канареечний випуск з автоматичним поверненням за метриками.
Обмеження перевірок варто зафіксувати заздалегідь — димовий набір не замінює навантажувальні випробування і не підтверджує коректність даних, він відповідає на питання, що система жива і ключові сценарії проходять.
Порядок впровадження перевірок у конвеєр доставки
Порядок впровадження залежить від зрілості релізного циклу, тому починаємо з аудиту, а не з налаштування: інакше перевірки дублюють ручні кроки і не покривають найдорожчі точки відмови. Нижче — порядок робіт, за яким ми ведемо впровадження перевірок у конвеєр доставки.
- Аудит релізного циклу. Карта шляху від коміту до промислового контуру: де залишилися ручні операції, як часто виходять релізи, скільки займає повернення до попередньої версії.
- Схема перевірок. 8–12 сценаріїв на питання «система жива»: доступність входу, авторизація, ключова операція читання і запису, доступність зовнішніх залежностей. Набір довший робить перевірку вузьким місцем релізу.
- Точка запуску і блокування. Перевірки йдуть після розгортання на стенд, але до перемикання трафіку: провал зупиняє викатку і повертає попередню версію.
- Налаштування конвеєра. Облікові дані тестового користувача — у сховищі секретів, тестові дані створюються і видаляються в рамках прогону, звіт з логами додається до збірки з міткою версії.
- Перевірка на навчальному збої. Навмисно ламаємо залежність і переконуємося, що конвеєр зупиняється, відкат проходить, а оповіщення приходить відповідальному.
- Передача в експлуатацію. Віддаємо регламент: хто додає сценарій, що робити при зміні зовнішнього інтерфейсу, як розбирати хибні спрацювання, плюс навчання чергової зміни.
Що залишається в репозиторії та документації
Набір артефактів фіксується до передачі, щоб черговий інженер не відновлював логіку перевірок за історією збірок. Все, що визначає поведінку smoke tests після деплою, лежить поруч з кодом сервісу і проходить рев'ю як звичайна зміна.
- Набори перевірок — по одному сценарію на критичний шлях: вхід, авторизація, ключовий запит до бази, зовнішня інтеграція, відповідь фонового обробника. Кожен помічений: блокує випуск або тільки попереджає.
- Шаблони конфігурацій оточень — адреси, сервісні облікові записи та таймаути для стенду, передпродуктивного і робочого середовища; секрети підставляються зі сховища.
- Розмежування прав — окремі ролі на ручний запуск, читання звітів і правку сценаріїв: змінити перевірку не означає отримати право на випуск.
- Регламент відкату — який результат вважається провалом, хто приймає рішення, до якого стану повертається реліз і як підтверджується, що попередня версія знову відповідає.
- Документація релізу — картка зміни: що зачеплено, які перевірки додані або зняті, які значення вважаються нормою.
- Інструкції для чергового — розбір типових спрацювань: як відрізнити хибне від реального збою, куди дивитися в журналі, кому ескалювати.
- Передача команді — розбір із супроводом на перших випусках і точка, після якої підтримку веде внутрішня команда.
Кейс: як скоротили час виявлення збою
Клієнт — команда, яка випускає оновлення кілька разів на день: вісім сервісів і спільний API для мобільного застосунку та вебу.
Регрес перед випуском йшов за чек-листом із 40 пунктів: вхід, оформлення замовлення, оплату та повідомлення інженер проходив руками — 25-35 хвилин на кожен випуск.
Збої в зв'язках між сервісами та в конфігураціях доходили до користувачів. Від викатки до першого сигналу проходило від 40 хвилин до кількох годин, а відкат запускали наосліп, без розуміння, що саме зламалося.
Що змінили
Зібрали smoke-набір з 14 сценаріїв, що відповідають на одне питання — чи живий продукт: доступність API, наскрізне замовлення, оплата в тестовому контурі, доставка подій у чергу, поведінка сервісу при недоступності сусіда. Прогін займає 2-3 хвилини.
Запуск прив'язали до двох точок: одразу після викатки в тестовий контур і після канареечного релізу на 10% трафіку. Падіння будь-якого кроку зупиняє розкатку і запускає відкат, а результати йдуть у Prometheus — видно, який сценарій почав падати після конкретної зміни.
Час виявлення збою скоротився до 2-4 хвилин замість 40-90. Відмови класу «сервіс не піднявся» і «невірна конфігурація» перестали доходити до користувачів: за місяць з кількох десятків випусків жоден не дожив до продакшену в неробочому вигляді.
Ручна перевірка перед випуском скоротилася приблизно на 80% — за чек-листом проходять лише релізні кандидати. Команда стала викатувати дрібніше і частіше: ціна помилки впала, а стабільність випусків зросла.
Що робити, якщо деплой іде, а перевірок немає?
Якщо конвеєр викладає код, а після викладення не запускається жодної перевірки, реліз вважається успішним за кодом повернення, а не за фактом працюючого сервісу.
Зелена збірка і бойовий контур, що впав — це не збій інструменту, а відсутній етап: між «артефакт розгорнуто» і «трафік переключено» немає воріт, здатних зупинити викладення. Симптоми при цьому повторюються від релізу до релізу, і за ними діагноз ставиться швидко.
| Симптом | Причина | Перша дія |
|---|---|---|
| Збірка зелена, сервіс віддає помилку шлюзу | Перевірка готовності формальна або її немає | Окремий маршрут готовності, опитування з повторами |
| Помилки знаходять користувачі | Немає прогону за критичними шляхами | 5-7 smoke-тестів: вхід, читання і запис ключової сутності, публічний маршрут |
| Міграції пройшли, застосунок не стартує | Сумісність схеми з попередньою версією не перевірена | Перевірка версії схеми до перемикання трафіку |
| Про збій дізналися через години | Немає обмеження прогону за часом і оповіщення | Таймаут прогону і оповіщення черговому в той самий канал |
| Відкат триває довше самого збою | Попередній артефакт не збережено, процедура не відрепетирувана | Зберігати останні артефакти і проганяти відкат на стенді |
Пріоритет впровадження простий: спочатку проба готовності, яка відрізняє процес, що піднявся, від сервісу, що реально приймає трафік, потім короткий набір smoke-тестів на критичні шляхи, потім прогін на канареечній групі з автоматичним відкатом при провалі.
Порядок дає ефект уже на найближчих релізах: час від викладення до сигналу про поломку скорочується з годин до хвилин, а smoke tests після деплою перестають бути ручною операцією чергового.
Технічні сумніви щодо димових перевірок
Димові перевірки ламаються не від відсутності інструментів, а від шуму: хибні спрацювання на кожному другому релізі, оточення, яке поводиться не як прод, і тестові дані, які виїжджають між прогонами.
Нижче — чотири сумніви, які найчастіше звучать на етапі оцінки, і те, як ми їх закриваємо інженерно.
Як відсікаєте хибні спрацювання, щоб алерти не вимкнули через тиждень?
Вважаємо частку шумних прогонів і тримаємо бюджет: якщо перевірка падає з інфраструктурної причини частіше, ніж раз на двадцять викаток, її або лагодять, або виводять з блокуючого набору в карантин з поміткою.
Нестабільні перевірки отримують повтор з обмеженою кількістю спроб і явним таймаутом на залежність — так відрізнимо реальну відмову сервісу від задумливого запиту зовнішнього постачальника.
Результат прогону йде в той самий канал, що й метрики викатки, тому причина видна без читання логів руками.
На якому оточенні запускати перевірки після викатки?
Перевіряємо на тому ж контурі, куди викотили: окремий «схожий на прод» стенд дає хибний спокій, бо розбіжності за конфігурацією і зв'язками спливають уже в користувачів.
Смоук-набір читає тільки ті адреси і ролі, які реально доступні після релізу, а доступи видаються сервісним обліковим записом з мінімальними правами. Для передпроду контур піднімається з тих самих шаблонів, що й прод, — інакше перевірка не переноситься.
Що робити з тестовими даними, щоб не зачепити реальні?
Кожен прогін працює зі своїми даними: префікс прогону в ідентифікаторах, окремий тестовий орендар, автоматичне очищення за часом життя.
Перевірки за замовчуванням тільки читають — створення і видалення об'єктів виносимо в окрему коротку групу, яку можна відключити на чутливому контурі. Так набір не залежить від стану бази і не накопичує сміття між релізами.
Хто підтримує набір перевірок після передачі?
Набір живе як код — у тому ж репозиторії, що й сервіс: додавання маршруту або зміна контракту йде однією зміною з рев'ю. Ми фіксуємо регламент: при новому критичному сценарії в чек-лист релізу додається перевірка, раз на квартал набір переглядається на застарілі кроки.
Після передачі ваші інженери правлять перевірки без нас — залишається прочитати документацію за структурою набору.
Обговоримо схему перевірок для вашого релізного циклу
Щоб схема перевірок після деплою лягла на ваш релізний цикл, а не зламала його, починаємо з короткого обговорення задачі.
Нам достатньо кількох вступних: як влаштоване викладення збірок, скільки середовищ і як часто ви випускаєте релізи, що вважається критичним шляхом для користувача.
З боку замовника зазвичай потрібні:
- доступ до репозиторію і налаштувань запуску збірок або вивантаження поточних конфігурацій;
- перелік середовищ і порядок просування збірки між ними;
- список ключових сценаріїв, відмова яких має блокувати реліз;
- облікові записи та тестові платіжні дані для прогону перевірок;
- вікно, в яке допустимо призупинити викладення при спрацюванні перевірки;
- контакт чергового інженера, який підтвердить критерії відкату на попередню версію.
Натомість повертаємося з оцінкою обсягу робіт і планом впровадження: які перевірки ставимо на автоматичний запуск після деплою, за який час проходить набір, на яких умовах він блокує просування збірки і як запускає відкат.
Схему перевірок запропонуємо у вигляді, готовому до роботи, а не до переказу: перелік кроків з очікуваним результатом, конфігурація запуску і відкату, розподіл перевірок на обов'язкові та інформаційні, порядок оповіщення чергових.
Далі — супровід релізів: розширюємо набір разом зі змінами продукту, щоб він не застарівав разом з критичними шляхами.
