Canary deployment: де ламається розгортання в прод
Класичне розгортання в прод надсилає нову версію одразу на весь трафік: піднімаються репліки з новим образом, старі гасяться, балансувальник перемикає всіх разом.
Якщо в коді помилка — невірний запит до схеми даних, витік з'єднань, падіння на рідкісному сценарії — її одночасно отримують усі користувачі. Перші звернення до підтримки надходять раніше, ніж графіки встигають показати зростання частки помилок.
Далі починається найдорожче — відкат релізу. Повернення на попередній образ сам собою швидкий, але якщо разом із кодом поїхала міграція схеми, відкат уже неповний: дані записані в новому форматі, частина обробників про них не знає.
Додайте сюди прогрів, перевірки готовності й повторне розгортання — і невдале оновлення розтягується на години ручних рішень.
Помилка в новому коді рідко буває тотальною. Частіше ламається один сценарій: оплата для частини регіонів, рідкісний формат файлу на вході, гілка за порожнього поля.
Різниця між «зламалося в усіх» і «зламалося в кількох відсотків» — це різниця між аварією та непомітною деградацією, про яку дізнаються з метрик, а не зі скарг.
Розбираємо, як це закривається. Канареечне розгортання (canary deployment) на Argo Rollouts переводить на нову версію спочатку невелику частку трафіку, звіряє частку помилок і час відповіді з базовою лінією та відкочує автоматично — без очікування чергового і без перезбирання.
Що дає поступове розгортання на частину трафіку
Поступове розгортання — це перенесення ризику з релізу на малу частку трафіку. Нова версія отримує вагу не цілком: 5%, потім 10, 25, 50 — із паузою на кожному кроці.
Поки контролер Argo Rollouts бачить, що метрики канареечного й стабільного середовищ зіставні, вага зростає; за відхилення трафік повертається на попередню версію.
Перевірки кроку задаються декларативно: частка відповідей із помилкою, 95-й перцентиль затримки, кількість перезапусків контейнерів. Поки пороги дотримані, розгортання йде далі саме, без ручного підтвердження.
Час відкату вимірюється десятками секунд, бо відкат — це зміна ваги, а не перезбирання й повторне розгортання.
Головне — усунений клас відмов. Дефект у коді або в налаштуваннях зачіпає малу частку користувачів замість усіх, і розбір залишається локальним інцидентом, а не загальною аварією з простоєм.
Частка зачеплених користувачів стає керованою величиною: її задають заздалегідь і змінюють під час розгортання.
Спостережуваність релізу зростає разом із цим: запити, логи й трасування позначені версією, тому видно, яку частину навантаження тримає канареечне середовище і як воно впливає на загальну картину.
Панель релізу показує зміну ваги та спрацьовані перевірки в одній шкалі часу — за нею видно, який крок пройшов гладко, а який спричинив відкат.
Звідси й вибір ширини каналу: спочатку випускають на внутрішній сегмент або на один регіон, потім розширюють до повної ваги. Така схема не замінює тести, але знімає головну ціну помилки — масовість.
Canary deployment проти синьо-зеленого та повного розгортання
Усі три схеми розв'язують одну задачу — довести нову версію до користувачів, але по-різному розпоряджаються трафіком і ціною помилки. Повне розгортання змінює всі екземпляри одразу: просто й передбачувано, але регресія миттєво поширюється на всю аудиторію.
Синьо-зелене тримає два середовища і переводить трафік повністю: відкат займає секунди, натомість нова версія одразу отримує повне бойове навантаження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Повне розгортання | Внутрішні сервіси та рідкісні релізи, де повернення — повторний випуск попередньої збірки | Помилку видно всій аудиторії, час між випуском і поверненням не обмежений |
| Синьо-зелене розгортання | Потрібен миттєвий відкат на попередню версію і є запас потужностей | Ресурси на час випуску подвоюються, реальний трафік не перевіряє версію частинами, міграції схеми потребують сумісності обох версій |
| Canary з перемиканням за вагами (Argo Rollouts) | Часті релізи, рівний трафік і налаштовані метрики помилок і затримок | Потрібна маршрутизація за вагами й автоматичний розбір показників, ускладнюються сесії та кеш |
Поступовий реліз виграє там, де є спостережуваність: вага зростає від часток відсотка до сотні, і регресію відсікають на перших відсотках трафіку, поки її бачать одиниці.
Якщо трафік невеликий і метрики шумлять, мала вага статистики не дає — тоді чесніше синьо-зелене розгортання або повний випуск із швидким поверненням. Критерій вибору — не мода, а метрики, автоматика відкату й сумісність міграцій схеми.
Етапи впровадження поступового розгортання в релізи
Поступове розгортання не прикручується поверх конвеєра — воно спирається на те, як влаштовані збірка, конфігурація та спостережуваність. Тому етапи впровадження йдуть від аудиту релізного процесу до регламенту, за яким черговий відкочує версію без автора релізу.
- Аудит релізного процесу. Дивимося, як збираються образи, чим відрізняються середовища, чи є метрики й трасування по сервісу. Без базової лінії за помилками й часом відповіді канареечне розгортання (canary deployment) нема з чим порівнювати.
- Підготовка маніфестів і розмітки. Застосунок отримує стабільний і канареечний набори подів, трафік ділиться за вагами через керований об'єкт на кшталт Argo Rollouts, версія видна в мітках і логах — інакше інцидент не відрізнити від минулого релізу.
- Перевірка на передпродуктивному середовищі. Проганяємо той самий маршрут на копії продакшену: кроки ваг, паузи, аналіз. Тут же перевіряємо відкат — він має повертати трафік і поди, а не залишати половинчастий стан.
- Налаштування метрик і порогів. Описуємо, що вважаємо деградацією: частка відповідей із помилкою, затримка на 95-му процентилі, нестача ресурсів. Пороги виводимо зі спостережуваної поведінки, інакше автоматичний відкат спрацьовує на шумі.
- Обкатка на реальному релізі. Перше розгортання ведемо з ручним підтвердженням кроків, інженер поруч дивиться метрики. Так видно реальну швидкість прогріву й те, які алерти шумлять марно.
- Передача регламенту. Віддаємо команді документ: кроки й паузи, умови автоматичного відкату, дії чергового, порядок ручного повернення. Канареечний етап стає обов'язковим пунктом чек-ліста релізу.
Конфігурації, схеми трафіку та регламенти передачі
Впровадження закінчується не працюючим розгортанням, а набором артефактів, за якими ваша команда сама змінює параметри й розбирає збої.
Усе це залишається у вашому репозиторії та кластері: конфігурації під контролем версій, доступи — у вашому контурі, інструкції прив'язані до кроків процесу, а не до конкретних людей.
- Конфігурації розгортання — опис об'єкта Rollout: частка трафіку на канареечній версії, паузи між кроками, умови автоматичного просування. Правки йдуть через merge request, а не руками в кластері.
- Схема трафіку — як балансувальник і Service ділять запити між стабільною та новою версією, включно з утриманням сесії та маршрутизацією за заголовком для внутрішніх перевірок. Віддаємо діаграмою й робочими маніфестами.
- Політики доступу — ролі на просування й відкат розгортання, розподіл прав між розробкою та експлуатацією, доступ до дашбордів метрик, заборона ручних змін у продовому просторі імен.
- Регламент відкату — що вважаємо деградацією, за якими метриками, хто ухвалює рішення, які команди виконуються і в якому порядку. Автоматичне повернення за порогом помилок описано окремо від ручного.
- Правила аналізу метрик — пороги за успішністю запитів, затримкою та частотою помилок, час спостереження на кожному кроці, поведінка за нестачі даних від сервісу метрик.
- Документація щодо інцидентів — шаблон розбору: на якому кроці розгортання зросли помилки, які метрики це показали, що змінили в конфігурації. Накопичені розбори задають наступні налаштування кроків.
- Інструкція для чергового — короткий сценарій: як призупинити розгортання, як повернути попередню версію, кого оповіщати і з яким інтервалом.
Кейс: частка користувачів, зачеплених збоєм, упала у 20 разів
Що було до впровадження
Замовник випускав оновлення мікросервісу повністю: нова версія ставала одразу на всі робочі поди. Будь-яка помилка в збірці зачіпала 100% активних користувачів, а сигнал надходив ззовні — від звернень до підтримки, а не з метрик. Відкат запускали вручну, на це йшло до 40 хвилин, і весь цей час збій тривав.
Що змінили
Ми перевели розгортання на поступовий сценарій у Argo Rollouts: нова версія отримувала спочатку 5% трафіку, потім 20% і 50%, і лише потім 100%.
На кожному кроці система звіряла частоту помилок і затримку відповіді з базовою лінією та утримувала реліз, якщо показник виходив за поріг. Кроки, пороги й умови паузи описали в маніфесті поруч із сервісом — розгортання стало частиною репозиторію, а не ручною операцією.
Що стало
Частка користувачів, зачеплених збоєм, скоротилася у 20 разів: проблемну версію встигало побачити не більше 5% аудиторії. Час відновлення впав із 40 хвилин до 2–3 — відкат спрацьовував автоматично за метрикою, без участі чергового інженера.
За квартал жоден дефектний випуск не дійшов до повного трафіку, а команда перестала боятися релізів наприкінці тижня.
Що робити, якщо релізи в кластері вже йдуть вручну
Перехід у вже розгорнутому кластері роблять не замість ручного розгортання, а поруч із ним: новий контур піднімається паралельно, частина сервісів продовжує виходити за старою схемою, решту переводять на канареечне розгортання (canary deployment) з поступовою часткою трафіку.
Поки нова версія не підтвердить себе на перевірках, попередній шлях залишається живим і слугує відкатом — зупиняти релізи не доводиться ні на день.
Міграція релізного процесу починається з інвентаризації: які сервіси розгорнуті, які маніфести їм відповідають, хто натискає кнопку і що перевіряється після.
Без цієї картини покроковий перехід перетворюється на переписування кластера повністю — саме той сценарій, де ламається прод.
Далі переводять по одному сервісу, починаючи з найменш критичного.
У маніфест додається об'єкт розгортання, що описує кроки й умови просування, до нього підключаються перевірки готовності та метрики, частка трафіку на нову версію зростає невеликими кроками, а кожен крок підтверджується вручну.
Результат видно того ж тижня: версія отримує реальне навантаження, а рішення про просування залишається за інженером.
Зворотність тут важливіша за швидкість. Якщо метрики просідають, трафік повертається на стабільну версію однією командою — це хвилини замість годин ручного перезбирання. Коли кілька релізів поспіль проходять без інцидентів, ручні підтвердження знімаються точково, а не всі одразу.
Сумніви щодо метрик, відкату й навантаження на прод
Пороги відкату — не здогадки, а параметри, які ми узгоджуємо до розгортання. Метрики релізу: частка помилок нової версії щодо базової, затримка на 95-му процентилі запитів і частка успішних бізнес-операцій.
Поки канареечна версія тримає 5–10% трафіку, вихід за поріг автоматично зупиняє розгортання й повертає трафік на стабільну версію.
Нижче — сумніви, які найчастіше виникають на узгодженні.
Як нова версія впливає на навантаження на базу даних?
Канареечна частка йде паралельно зі стабільною, тому запити обох версій живуть в одній схемі. Міграції робимо розширювальними: спочатку додаємо колонку або індекс, сумісні зі старим кодом, потім перемикаємо застосунок і лише після виведення попередньої версії прибираємо зайве. Зворотні зміни застосовуємо після повної заміни — інакше відкат упирається в несумісну схему.
Хто ухвалює рішення про зупинку розгортання?
Автоматика за порогами: перевищення частки помилок або затримки повертає трафік на стабільну версію без участі чергового. Ручна зупинка залишається — вона потрібна, коли ззовні видно те, чого немає в метриках, наприклад скарги на конкретний сценарій.
Які обмеження має підхід?
Канареечне розгортання марне, якщо трафік занадто малий для статистики, якщо немає спостережуваності за потрібними метриками або якщо реліз змінює формат даних несумісно.
Фонові завдання та черги ділить не балансувальник, а самі обробники — для них перевірку будуємо окремо, за часткою оброблюваних задач.
Обговоримо задачу: повернемося з оцінкою та планом
Щоб розмова була предметною, достатньо принести поточний стан доставки змін: як реліз потрапляє в прод сьогодні, чи є окремий контур для перевірок, які метрики вже збираються із застосунку.
Частина даних може бути відсутня — вимоги до інфраструктури та правила розгортання сформулюємо разом, спираючись на те, що є.
У відповідь ви отримуєте робочу рамку, а не загальні міркування: оцінку строків за етапами, план впровадження з точками контролю та схему розподілу трафіку між версіями. Нижче — що зазвичай потрібно від замовника і що ми готуємо зі свого боку.
- Доступи: читання кластера, репозиторію маніфестів і системи збирання образів — цього достатньо, щоб розібрати поточний процес, нічого не змінюючи.
- Поточний спосіб розгортання: де саме ухвалюється рішення про перехід на нову версію — вручну, скриптом або правилами конвеєра.
- Спостережуваність: які метрики знімаються, куди пишуться і чи можна порівняти дві версії за однаковими правилами.
- Вимоги до інфраструктури: запас ресурсів під дві версії одночасно, окремий контур для перевірок, керування трафіком на вході в кластер.
- Правила відкату: за яким показником розгортання вважається невдалим і скільки часу займає повернення на попередню версію.
- Ролі та межі: хто розширює частку трафіку, хто чергує і як передається керування після запуску.
Опишіть задачу у вільній формі — повернемося з оцінкою та планом впровадження, де буде видно порядок кроків, склад робіт і зони відповідальності.
