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 будуємо на статусах об'єктів, а не на паузах.
Що з підтримкою набору перевірок після передачі?
Віддаємо його разом із регламентом: які перевірки обов'язкові перед викаткою, як підключити новий контур, де дивитися історію прогонів. Перший час супроводжуємо самі — правимо пороги й додаємо сценарії під зміни інфраструктури, далі набір веде команда замовника.
Обговоримо вашу задачу і повернемося з планом перевірок
Щоб повернутися з оцінкою та планом перевірок, а не із загальними словами, нам потрібні від вас три речі: опис контуру (хмара, власні сервери або змішана схема), поточний спосіб провізіонінгу і список інцидентів, які ви вже ловили руками.
Якщо є логи викатки та конфігурації — додайте, цього достатньо, щоб побачити точки відмови без довгих розпитувань.
Далі працюємо у два проходи: спочатку розбираємо контур і збираємо перелік перевірок, потім узгоджуємо обсяг. Повертаємося з пакетом:
- карта інфраструктури з місцями, де відмова проходить непоміченою аж до продакшену;
- склад перевірок після провізіонінгу: доступність сервісів, стан залежностей, коректність прав і змінних середовища, поведінка при перезапуску вузла;
- схема вбудовування в конвеєр постачання: які перевірки блокують викатку, які лише сигналять черговому;
- вимоги до доступів і тестових середовищ, де проганяємо перевірки;
- оцінка робіт за етапами з розділенням: що закриваємо ми, що залишається на вашому боці;
- строки впровадження — від узгодження складу до перших прогонів на бойовому контурі та передачі документації.
Опишіть задачу у вільній формі: який контур, чим розгортається, що вже ламається. Ми повернемося з оцінкою, планом перевірок і строками впровадження.
