Blue-Green vs Canary Deployment та інші стратегії: як релізити код з меншим ризиком

AI-агенти пишуть дедалі більше коду, і великі компанії вже перебудовують під це свої процеси. У Meta за рік обсяг коду в одній зміні зріс на 106%, і понад 80% цього приросту дали AI-агенти. Рев'юери за таким обсягом не встигають, тому частину змін тепер перевіряє система RADAR: вона сама оцінює ризик і вливає в основну гілку зміни з низьким ризиком.

Коли код пишуть і перевіряють агенти, дедалі важливішим стає те, як зміна потрапляє до користувачів. Розбираємося, як працюють blue-green deployment, canary deployment і rolling update і як вибрати стратегію для свого продукту. Олексій Румянцев, Head of Engineering в COPYMIND, поділився, як влаштований реліз у команді, де більшість коду пише AI-агент: від trunk-based development до ручного відкату за секунди.

Чому deployment strategy знову важлива: AI, конфіги й ціна аварій

Якщо нова версія одразу дістається всім, помилка теж відразу стосується всіх, а відкочуватися доводиться, коли продукт уже лежить. Стратегія релізу визначає, скільки користувачів побачать помилку, перш ніж її помітять. У термінах DORA вона впливає на дві метрики стабільності: change failure rate, тобто частку невдалих змін, і час відновлення після невдалого деплою (його часто називають MTTR). Три тенденції роблять це питання гострішим:

1. Коду більше, ніж можна перевірити вручну

За даними DORA, у 2025 році AI використовували 90% розробників. Пропускна здатність команд зростала, але використання AI «пов'язане зі зростанням нестабільності». У Meta за рік обсяг коду в одній зміні зріс на 106%, і понад 80% приросту дали AI-агенти. Згідно з опитуванням 300 інженерних керівників, 35% згенерованого коду потрапляє в продакшн раніше, ніж команда його повністю розуміє. У березні 2026 року сайт Amazon приблизно на шість годин втратив можливість проводити транзакції через помилковий деплой. Внутрішні документи пов'язували серію таких інцидентів зі змінами, зробленими за допомогою AI, хоча сама Amazon це заперечує.

2. Аварії спричиняє не лише код, а й конфігурація 

Увечері 28 вересня 2026 року тисячі застосунків для iPhone і iPad почали падати одразу після запуску. Винним виявився вбудований у них SDK Google Analytics for Firebase. Під час планового прибирання команда Firebase видалила з бекенду старий фіче-флаг. Зміна одночасно пішла на всі продакшн-сервери, і вони почали віддавати конфігурацію в неправильному форматі. SDK не був готовий до такої відповіді й аварійно завершував роботу застосунку. Падали не сервери, а клієнти, тому метрики й сторінка статусу нічого не показували. 

14 липня 2026 року у Coinbase на 50 хвилин зупинилися торгівля, перекази й операції за картками. Плановий «низькоризиковий» апдейт конфігурації Kubernetes-кластера спричинив конфлікт імен ресурсів, який не виявили перевірки перед продакшеном. 

3. Аварії дорожчають

57% опитаних Uptime Institute повідомили, що їхня остання велика аварія коштувала понад $100 000, а кожен п'ятий — що понад $1 млн. 

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

Як працює Blue Green Deployment

Ідея Blue Green Deployment дуже проста. Мартін Фаулер описав цей підхід ще у 2010 році, і його головна перевага відтоді не змінилася. У команди є два однакові продакшн-середовища. «Синє» обслуговує користувачів, а на «зелене» викочують нову версію і перевіряють її, поки трафіку там немає. Коли все гаразд, трафік перемикають на «зелене». «Синє» залишається поруч, і якщо щось піде не так, трафік так само швидко повертають назад.

У Kubernetes таке перемикання може бути буквально одним рядком: у селекторі сервісу мітку version: blue змінюють на version: green, і трафік іде вже на нові поди. 

Тривалий час аргументом проти blue-green deployment була ціна: потрібна подвійна інфраструктура. Для фізичних серверів так і було. У Kubernetes «два середовища» — це зазвичай дві версії одного сервісу в тому самому кластері. Наприклад, в open-source контролері Argo Rollouts продакшн-трафік іде через основний сервіс (active), а нову версію перевіряють через попередній (preview). Перед перемиканням можна запустити автоматичний аналіз метрик. Стару версію контролер за замовчуванням вимикає вже через 30 секунд після перемикання. Тож подвійні ресурси потрібні лише на час перевірки і короткого запасу для відкату.

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

З таким підходом працює Netflix. У липні 2026 року компанія розповіла, що оновлює власні LLM за схемою red-black (так у компанії називають blue-green): трафік поступово переходить на нову версію моделі. Проблема виникла там само, де й у класичному blue-green, — у сумісності. Якщо нова модель змінює формат вхідних чи вихідних даних, сервіси, які до неї звертаються, не встигають оновитися, і частина запитів падає. Для таких випадків Netflix тримає кілька версій моделі одночасно.

Blue-green deployment варто обирати, коли потрібен миттєвий відкат. Але в нього є суттєве обмеження: перемикання відбувається для всіх користувачів одразу. Якщо проблема проявляється лише під реальним навантаженням, її побачать усі.

Як працює Canary Deployment

Назва походить із досвіду шахтарів: вони брали з собою до шахти канарку, бо вона реагувала на газ раніше за людей. У релізах цю роль виконує невелика частка трафіку. Спершу нова версія обслуговує, наприклад, 2% користувачів, а решта йде на стару. Якщо метрики в нормі, частку поступово доводять до 100%. Якщо ні, трафік повертають на стару версію, і помилку бачить лише невелика група користувачів.

Якщо Blue-green перевіряє нову версію до запуску, та canary deployment — під час запуску, на реальному навантаженні. Тому цей підхід знаходить проблеми, яких немає в тестах: несподівані сценарії, поведінку під піковим навантаженням, збої в окремих групах користувачів.

Раніше інженер вручну перемикав частину трафіку і стежив за графіками. Тепер це роблять контролери, які перевіряють метрики за заданими правилами. У прикладі з документації Flagger нова версія щохвилини отримує ще 2% трафіку, якщо метрики в нормі, і за 25 хвилин доходить до 50%. У разі помилки, сам повертає весь трафік на стару версію.

Ось як виглядають кроки canary-викатки в Argo Rollouts:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: checkout
spec:
  strategy:
    canary:
      steps:
        - setWeight: 5            # 5% трафіку на нову версію
        - pause: {duration: 10m}
        - analysis:               # блокує викатку до результату
            templates:
              - templateName: error-rate
        - setWeight: 25
        - pause: {duration: 30m}
        - setWeight: 50
        - pause: {}               # чекати ручного підтвердження

Якщо аналіз error-rate не пройде, викатка зупиниться, а трафік повернеться на стару версію. Крок pause: {} залишає останнє рішення перед повним релізом за людиною (Argo Rollouts).

Для canary deployment потрібні інструмент розподілу трафіку (балансувальник, service mesh чи Gateway API) і надійні метрики. Без них canary стає звичайною викаткою, тільки повільнішою. Стара і нова версії довго працюють паралельно, тож обидві мають коректно працювати з тими самими даними. Сам реліз триває від десятків хвилин до кількох годин, тому для термінових виправлень він незручний. Зате canary дає перевірити нову версію на реальних користувачах і обмежити ризик невеликою їх групою.

Rolling Update: стратегія за замовчуванням, з якої починають усі

Rolling deployment замінює екземпляри старої версії новими невеликими партіями, поки не оновляться всі. У Kubernetes цю стратегію називають rolling update, і вона працює за замовчуванням. Під час оновлення недоступними можуть бути до 25% подів, а ще до 25% можна тимчасово запустити понад потрібну кількість. Якщо нові поди не запускаються, наприклад, через помилку в образі, Kubernetes не замінює решту старих.

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

Відкат теж не автоматичний. Якщо викатка застрягла, Kubernetes лише позначає її як невдалу, а відкотити версію має людина або зовнішній інструмент (Kubernetes). Сам відкат — це ще один rolling update у зворотний бік, тому миттєвим він не буде. Крім того, стратегія керує кількістю подів, а не трафіком: частка користувачів, які бачать нову версію, приблизно дорівнює частці оновлених подів, і точно задати частку трафіку, як-от 1%, не вийде.

Rolling deployment добре підходить для внутрішніх і некритичних сервісів. Коли ціна помилки зростає, його доповнюють аналізом метрик, як у canary, або миттєвим перемиканням, як у blue-green.

Blue-Green vs Canary vs Rolling Deployment: головні відмінності

На практиці ці стратегії часто поєднують. Blue-green доповнюють поступовим перемиканням трафіку, як у Netflix, або автоматичним аналізом метрик перед перемиканням. Будь-яку зі стратегій можна поєднати з фіче-флагами: код викочують вимкненим, а функцію вмикають для користувачів окремо, тож деплой і реліз стають двома різними подіями. А різні сервіси в одній компанії можуть отримувати різні стратегії: rolling update для внутрішніх інструментів, canary для платежів.

Canary Release на практиці: перша група, метрики і критерії зупинки

Першою групою часто стають власні співробітники. Facebook спершу показував нову версію лише працівникам, з усіма увімкненими фіче-флагами. Інші варіанти — випадкова вибірка запитів або окремий сегмент, як-от країна чи платформа. Але результат на сегменті не завжди можна переносити на всіх користувачів. Google SRE радить запускати лише одну canary-викатку одночасно, інакше неможливо зрозуміти, яка зміна спричинила проблему.

Тривалість не менш важлива, ніж відсоток трафіку. Canary має пройти через пікове навантаження, бо проблеми з продуктивністю часто проявляються лише під ним. Для фонових задач він має тривати щонайменше один повний цикл обробки. Добрий приклад поступового збільшення — поетапний реліз в App Store: оновлення отримують 1%, 2%, 5%, 10%, 20%, 50% і, нарешті, 100% користувачів з автоматичними оновленнями за сім днів. Проте будь-хто може оновитися вручну, тож у мобільних застосунках поетапний реліз не замінює можливості вимкнути функцію з сервера.

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

Типова пастка — загальний дашборд. Якщо 5% трафіку отримують 20% помилок, на загальному графіку це лише близько 1%. Тому canary порівнюють із контрольною групою, яка в той самий час працює на старій версії, а не з показниками до релізу. Інакше різницю між буднями й вихідними легко сплутати з ефектом нової версії.

Перед запуском canary release варто перевірити кілька речей:

1. Визначені перша група і кроки збільшення трафіку, а також час на кожному кроці.

2. Обрано 3-5 метрик, серед них одна продуктова, і є контрольна група для порівняння.

3. Записані пороги для трьох рішень: продовжити, відкотити, поставити на паузу.

4. Зрозуміло, хто ухвалює рішення в неоднозначних випадках.

5. Перевірено, що відкат працює, а зміни в базі даних сумісні з обома версіями.

Поетапна викатка — не єдиний спосіб зменшити ризик. Команда COPYMIND обходиться без класичного canary, працює за trunk-based development моделлю і робить ставку на суворі автоматичні перевірки до релізу і швидкий відкат.

Як влаштований реліз в AI-продукті

Коли релізите не код: конфіги, AI-моделі й промпти

Якщо продукт працює з мовною моделлю, команда постійно випускає зміни, які не виглядають як релізи: нові промпти, версії моделей, описи інструментів, налаштування. Тим часом AI-функції ламаються тихо. Сервіс працює і відповідає швидко, але відповіді стають гіршими, і на графіку помилок цього не видно. Такі регресії часто помічають лише через тижні, зі скарг користувачів, тому коротка canary-викатка їх просто не встигне побачити. Навіть AI-лабораторії в постмортемах визнавали: зміни промптів тижнями проходили внутрішні перевірки без жодних регресій і все одно погіршили продукт.

Тому для AI-функцій перед canary можна додати shadow traffic, або dark launch. Нова версія отримує копію реальних запитів, але її відповіді не бачать користувачі: їх лише порівнюють із відповідями старої версії. Так можна оцінити якість на реальних даних, не ризикуючи досвідом користувачів, хоча вимоги до обробки персональних даних тут теж треба враховувати. Сам canary для AI-функцій теж відрізняється від звичайного:

• окрім помилок, стежать за якістю: оцінками відповідей на вибірці запитів, часткою передач оператору, відгуками користувачів;

• рахують вартість, бо новий промпт може працювати добре, але витрачати вдвічі більше токенів;

• спостерігають довше, бо кількох хвилин, достатніх для коду, тут мало;

• тримають кожну розмову на одній версії, інакше дані обох груп змішаються.

Водночас AI допомагає керувати й самими релізами. У 2026 році Meta описала систему RADAR, яка оцінює ризик змін, а зміни з низьким ризиком сама переглядає і вливає в основну гілку. Їх відкочують утричі рідше, а аварії через них трапляються в 50 разів рідше, ніж через решту змін. Щоправда, автоматично проходять якраз найпростіші зміни, тож порівняння не зовсім рівне.

Чаріті Мейджорс, співавторка книжки Observability Engineering, у подкасті The Pragmatic Engineer поставила питання, яке зараз обговорюють багато команд: що потрібно, щоб інженер спокійно випускав код, якого не читав? Її відповідь: якщо довіра до коду падає на етапі написання, її треба набирати на етапі перевірки — тестами, евалами і спостереженням за продакшеном. 

Як вибрати deployment strategy для свого продукту

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

• Фінтех. Canary з продуктовою метрикою, як-от частка успішних платежів, і ручним підтвердженням на ключових етапах. Для великих змін — blue-green, а міграції лише за схемою expand and contract.

• Стартап на етапі MVP. Rolling update за замовчуванням і фіче-флаги, щоб вимкнути нову функцію за секунди. Canary має сенс, коли трафіку вистачає для статистично значущого сигналу.

• Мобільний застосунок. Опублікований реліз не відкотиш, тому основний захист — поетапне оновлення в магазині застосунків і серверні флаги для нових функцій. Бекенд має довго підтримувати і стару, і нову версію застосунку.

• Продукт з AI-функціями. Код, промпти й моделі — окремі релізи з різним ризиком. Для коду підійде звичайний canary, для моделей і промптів — довший, з метриками якості й вартості.

Найбільше на безпеку релізу впливає не вибір стратегії, а розмір зміни. Автори звіту DORA про ROI від AI-розробки радять боротися з нестабільністю автоматичним тестуванням, безперервною інтеграцією і малими порціями змін. Тому практичніше мати не одну стратегію на все, а правило вибору для кожної зміни. Дрібне виправлення внутрішнього сервісу може піти rolling update за кілька хвилин, зміна в платежах — повільним canary, а нова функція — чекати вимкненою за флагом. Що більше змін пишуть AI-агенти, то важливіше записати ці правила заздалегідь, а не вигадувати їх під час інциденту.

FAQ