Автоматичний відкат у разі невдалого деплою в Kubernetes

Автоматичний відкат: де ламається розгортання в Kubernetes

Збій випуску рідко виглядає як провал на етапі збирання.

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

Перевірки перед випуском охоплюють відтворювані сценарії: сервіс стартував, ендпоінт відповідає, міграції застосувалися. Поведінка під реальним навантаженням, на прогрітому кеші та з повільними зовнішніми залежностями в них не відтворюється.

Окрема пастка — несумісна зміна схеми даних: застосунок відкочується, а стан залишається в новому форматі, і попередня версія падає вже на ньому.

Гірше інше: відкат релізу тримається на людині. Черговий отримує оповіщення, читає логи, телефонує автору зміни, згадує команду повернення до попереднього стабільного стану — і все це під тиском, поки деградація триває.

Кожна хвилина такого розбору оплачується недоступністю сервісу, а поспіх додає помилок: повернули не той образ, забули про залежний сервіс, залишили увімкненим новий режим обробки.

Автоматичний відкат прибирає із цього ланцюжка дзвінок і рішення за настроєм.

Випуск сам звіряє метрики після виходу нової версії з порогами, і якщо частка відмов або час відповіді виходять за межі, робоче навантаження повертається до попереднього стабільного стану без участі людини — за секунди, а не за час на пошук чергового.

Далі розбираємо, як це влаштовано і які умови потрібно закрити, щоб відкат спрацьовував надійно, а не перетворювався на ще одне джерело збоїв.

Що змінюється після впровадження керованих відкатів

Керований відкат — це не кнопка «повернути як було», а політика випуску: рішення про відкат ухвалює контролер за метриками, а не черговий інженер. Кластер Kubernetes тримає попередній набір реплік, і повернутися до нього можна без ручного збирання. Невдалий реліз перестає бути інцидентом і стає штатним сценарієм.

Час відновлення скорочується з десятків хвилин до одиниць: поки інженер читає оповіщення й вирішує, лагодити чи відкочувати, система вже повернула попередню версію.

Простій сервісу обмежується одним циклом перевірки готовності — користувачі найчастіше не встигають помітити деградацію.

Частка ручних дій у відкаті падає майже до нуля: не потрібно шукати попередній тег образу, правити маніфести й перезапускати випуск.

Поріг спрацьовування задається заздалегідь — частка помилок, затримка відповіді, кількість невдалих перевірок готовності, — тому поведінка системи відтворювана й не залежить від того, хто сьогодні на зміні. Ручним залишається розбір причини.

Третій ефект — клас відмов, який перестає доходити до користувачів: помилка в конфігурації, несумісна зміна схеми даних, деградація під навантаженням одразу після випуску.

Четвертий — передбачуваність і стабільність релізів: команда випускає частіше й меншими порціями, бо ціна помилки обмежена одним автоматичним відкатом, а не нічним розбором.

Стратегії випуску та момент спрацьовування відкату

Стратегія випуску визначає не лише швидкість доставки змін, а й те, наскільки рано система помічає збій і може повернутися до попередньої версії.

Автоматичне повернення спирається на два параметри: поріг помилок — частка невдалих запитів або зростання часу відповіді щодо базової лінії, і вікно спостереження — час, протягом якого метрики мають залишатися в нормі до переведення всього трафіку на нову версію.

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

Поріг помилок ставлять із запасом до звичайного фону сервісу, інакше відкат спрацьовує на штатних сплесках навантаження. Занадто коротке вікно спостереження дає хибні спрацьовування, занадто довге — розтягує час, коли збій бачать користувачі.

Обидві величини калібрують за історичними метриками конкретного сервісу, а не за загальними рекомендаціями з документації.

Впровадження автоматичного відкату: шість етапів

Автоматичний відкат — не одне налаштування, а контур, який проходить шлях від інвентаризації випусків до передачі в експлуатацію.

Порядок етапів принциповий: якщо увімкнути повернення в Kubernetes раніше, ніж зведено сигнали збою, перший же хибний відкат заведе прод у версію, гіршу за збійну.

1. Інвентаризація випусків. Зводимо всі шляхи потрапляння коду в прод: конвеєри збирання, ручні правки, регулярні завдання. Усе, що не залишає сліду для повернення, або закриваємо, або плануємо окремим пунктом.
2. Визначення сигналів збою. Домовляємося, що вважаємо невдалим випуском: провал перевірки готовності, зростання частки помилок, невихід на планове навантаження. У кожного сигналу поріг і час витримки — інакше відкат смикається на штатних коливаннях.
3. Зберігання попередніх версій. Фіксуємо, на скільки релізів назад доступний відкат, де лежать попередні образи й маніфести та за який час версія повертається в роботу.
4. Налаштування відкатів. Правила прописуємо в самому випуску: який сигнал вмикає повернення, хто отримує повідомлення, що відбувається з трафіком і міграціями даних. Несумісні зміни схеми розбираємо окремо — їх поверненням не лікують.
5. Перевірка готовності. Вчимо відкат на стенді: валимо реліз штучно, заміряємо час повернення, звіряємо стан сервісу й даних із попереднім. Так перевіряються і пороги, і відсутність хибних спрацьовувань.
6. Обкатка в проді. Вмикаємо автоматику спочатку на одному сервісі з вузькою зоною впливу, потім розширюємо й ведемо журнал спрацьовувань.
7. Передача в експлуатацію. Черговій зміні надходить регламент: порядок розбору кожного відкату, точки контролю та правила правки порогів.

На виході відкат спрацьовує за перевіреним сценарієм, а розбір причини займає хвилини, а не години.

Що залишається в кластері та репозиторії після робіт

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

• Маніфести робочих навантажень, сервісів і правил входу — у системі контролю версій, з лімітами ресурсів, пробами готовності й живучості та політикою оновлення реплік. Будь-яка зміна проходить рев’ю, а не правиться руками в кластері.
• Шаблони середовищ: налагоджувальний, передпродуктивний і продуктивний контури відрізняються значеннями параметрів, а не копіями файлів — розходження між стендами перестає бути джерелом сюрпризів.
• Схема випуску: порядок кроків, точка ухвалення рішення й набір сигналів — частка успішних відповідей, час готовності, частка помилок за вікно спостереження. За ними розгортання або закривається успішно, або відкочується автоматично.
• Конфігурація автоматики відкату: пороги спрацьовування, кількість спроб, глибина історії ревізій для повернення, правила повідомлення чергової зміни. Окремо описано, за яких умов автоматика зупиняється й кличе людину.
• Регламент чергування: склад зміни, час реакції, порядок передачі зміни, критерії інциденту та межі, де черговий діє сам, а де потрібне погодження.
• Документація з відкатів: покрокові сценарії повернення релізу, скасування зміни схеми даних і відновлення з резервної копії — із зазначенням виконавця та очікуваного часу відновлення.
• Дашборди й правила оповіщень, прив’язані до тих самих сигналів, що використовує автоматика, — черговий бачить ту саму картину, що й система.

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

Кейс: ручний відкат за дзвінком проти автоматики

Що було: відкат за дзвінком

Випуск проходив успішно, але за кілька хвилин нова версія починала віддавати помилки на частині запитів. Першим дізнавався черговий — із повідомлення моніторингу, іноді від підтримки.

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

Що змінили і що стало

Автоматичний відкат будується на метриках вікна спостереження після випуску: якщо частота помилок або час відповіді виходять за поріг, випуск зупиняється і трафік повертається на попередню версію.

Умови описали декларативно через Argo Rollouts, щоб пороги жили в репозиторії й змінювалися лише через рев’ю, а не правкою руками на кластері.

Окремо закрили клас відмов «деградація в неробочий час»: раніше він тягнувся до ранку, бо піднімати людей на розбір ніхто не хотів. Тепер рішення ухвалює автоматика, а черговий отримує готовий факт — версію відкочено, логи додано.

Чим відкат за метриками відрізняється від відкату за образом?

Автоматичний відкат запускається або за поведінкою сервісу, або за станом випуску.

Відкат за метриками дивиться на частку помилкових відповідей, час відгуку й глибину черги у вікні спостереження: якщо значення виходять за поріг із політики, випуск переривається, а трафік повертається до попередньої ревізії без чергового.

Такий тригер ловить деградацію, яку не спіймали перевірки готовності — зростання помилок на частині запитів, просідання під реальним навантаженням, витік пам’яті в перші хвилини.

Відкат за версією образу — повернення до відомого робочого артефакту: нова ревізія не проходить перевірки або падає на старті, і система розгортає попередній зібраний образ.

Тригер тут не поведінка, а факт невдалого випуску: контейнер не піднімається, розкатка не вкладається у відведений час.

Різниця в природі сигналу: метрики відповідають на питання «чи стало гірше користувачу», образ — «чи дійшла нова версія до робочого стану».

Перший точніший за змістом, але потребує базової лінії та вікна спостереження; другий швидший і передбачуваніший, але пропускає деградацію, що проявилася після успішного старту.

Вибір тригера залежить від характеру сервісу. Для сервісів без стану працює зв’язка: повернення за образом при невдалій розкатці плюс автоматичний відкат за помилками й часом відповіді у вікні спостереження.

Для сервісів із міграціями схеми та станом повернення небезпечніше — пороги ставлять ширше, а рішення частіше залишають за інженером.

На практиці ми вмикаємо обидва контури: канареечний випуск на частку трафіку, вікно спостереження з порогами за звичайною поведінкою сервісу та журнал, за яким видно, який тригер спрацював.

Часті технічні сумніви перед впровадженням

Перед стартом робіт інженери та керівники напрямку ставлять майже ті самі питання. Нижче — прямі відповіді: як відокремлюються відмови коду від відмов даних, чим гаситься хибне спрацьовування автоматики і що відбувається, якщо вона помиляється.

Автоматика не почне відкочувати реліз на рівному місці?

Спрацьовування потребує не одного, а серії провалів: частка помилок і затримки виходять за поріг протягом вікна спостереження, і перевірки живучості не відновлюються самі. Пороги налаштовуються за реальним профілем навантаження, а не за замовчуванням.

Що робити, якщо відкат пройшов, а причина збою залишилася?

Автоматика повертає систему в останній робочий стан і фіксує зріз метрик та логи на момент збою. Далі розбір іде за цим зрізом, а повторний випуск можливий лише після явного підтвердження — захист від циклічного випуску.

Чи можна відкочувати не весь реліз, а одну групу?

Так, при поетапному випуску відкат стосується лише тієї частини навантаження, де з’явилися помилки, решта продовжує працювати на новій версії. Реєстр образів при цьому тримає останні робочі збірки, щоб повернення було можливим у будь-який момент.

Як це пов’язано з доступами та правами?

Відкат виконує сервіс доставки, а не людина, тому інженерам не потрібно тримати розширені права в продуктивному середовищі. Ручний запуск залишається доступним черговому, кожна дія пишеться в журнал із зазначенням ініціатора.

Обговоримо вашу схему випуску та пороги відкату

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

• Схема випуску. Як оновлюється робоче навантаження: поступова заміна подів з обмеженням на кількість недоступних екземплярів або канареечні кроки з керуванням вагою трафіку. Якщо в контурі вже є контролер прогресивного випуску — назвіть його, це скорочує обсяг робіт.
• Тригери деградації. Яка метрика вважається сигналом: частка відповідей 5xx на вхідному шлюзі, затримка 95-го процентиля, кількість рестартів контейнерів, глибина черги. І за який інтервал накопичуємо значення, щоб відрізнити збій від одиничного сплеску.
• Пороги відкату. За якого значення метрики і після скількох послідовних вимірювань запускаємо повернення. Окремо — мінімальна кількість запитів на вікно, інакше автоматика спрацює на порожньому трафіку.
• Вікно спостереження. Скільки тримаємо нову версію під малою часткою трафіку і з яким кроком розширюємо. Від цих чисел залежить, чи встигне дефект проявитися до повного випуску.
• Доступи та тестовий контур. Доступ до кластера лише на читання або вивантаження метрик, наявність середовища з подібним профілем навантаження, де спрацьовування відкату перевіряється без ризику для бойового трафіку.
• Межі автоматизації. Що відкотити не можна: міграції схеми даних, сервіси зі станом, несумісні зміни контрактів. Для них потрібен ручний сценарій і зрозумілий порядок дій чергового.
• Критерій невдачі. Падіння бізнес-показника або лише технічна помилка. Від цього залежить, хто ініціює повернення і чи потрібне підтвердження людини.

За підсумками розмови повернемося з картою поточної схеми випуску, набором порогів відкату та планом впровадження з явними межами робіт — що закриваємо автоматикою, а що залишається за черговою зміною.