Що таке canary release і як випускати зміни без стрибка у прірву

Зачіпка

Canary release - це спосіб випустити зміну не одразу всім, а спочатку маленькій частині користувачів. Ідея проста: якщо нова версія поводиться погано, краще дізнатися про це на 1% трафіку, а не на всьому production.

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

Проблема / Контекст

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

Canary release зменшує blast radius. Нова версія потрапляє тільки до малої частини аудиторії або до окремого сегмента. Команда дивиться на error rate, latency, логи, бізнес-метрики і порівнює їх зі стабільною версією. Якщо все рівно, traffic split збільшують. Якщо ні, rollout зупиняють.

Це частина ширшого підходу progressive delivery. Зміни не просто кидають у production, а відкривають поступово: через traffic split, feature flag, окремі регіони, окремі команди або інші контрольовані групи.

Чому це важливо

Для користувача не має значення, наскільки красиво виглядав реліз у deploy pipeline. Якщо після нього не працює оплата, авторизація або головна сторінка, проблема вже реальна.

Canary release допомагає виграти час. Команда бачить сигнал раніше, поки зачеплено мало людей. Це особливо корисно для змін, де staging не може повністю повторити production: реальний трафік, різні браузери, нестандартні дані, інтеграції, черги, кеші.

Ще одна користь - менше паніки. Коли заздалегідь є стоп-умови, рішення не треба вигадувати під тиском. Наприклад: якщо error rate у canary-версії вдвічі вищий за стабільну протягом 10 хвилин, rollout зупиняємо і робимо rollback.

Але canary release має сенс тільки тоді, коли ви справді можете порівняти стару і нову версію. Якщо немає метрик, логів і швидкого rollback, canary перетворюється на красиву назву для звичайного ризикового релізу.

Як це працює

Уявімо API-сервіс. Стара версія вже обробляє весь трафік. Нова версія пройшла staging і готова до production. Замість того щоб перемкнути всіх одразу, команда робить маленький traffic split:

stable version: 99% traffic
canary version: 1% traffic
watch time: 15 minutes

Після цього команда дивиться не на відчуття, а на конкретні показники:

error rate;
latency;
кількість 5xx-відповідей;
споживання CPU і пам’яті;
бізнес-події, які має не зламати реліз;
логи з canary-версії.

Якщо показники нормальні, наступний крок може бути таким:

stable version: 90% traffic
canary version: 10% traffic
watch time: 30 minutes

Далі трафік піднімають до 25%, 50%, 100% або зупиняють раніше. Конкретні числа не священні. Важливо, щоб кроки були достатньо малими для ризику зміни і достатньо великими, щоб побачити реальні сигнали.

Як це зробити

1. Виберіть зміну, яка підходить для canary

Canary release добре працює для backend-сервісів, frontend-версій за CDN, edge-правил, worker-ів і функцій, які можна вмикати поступово. Гірше - для незворотних міграцій бази даних, одноразових скриптів або змін, які одразу змінюють спільний стан для всіх користувачів.

Якщо зміна має database migration, спочатку перевірте сумісність старого і нового коду. Canary не врятує, якщо нова версія змінює дані так, що стара вже не може працювати.

2. Підготуйте маршрутизацію

Потрібен механізм, який реально вміє ділити трафік. Це може бути load balancer, Kubernetes ingress, service mesh, CDN, edge-платформа або feature flag на рівні застосунку.

Не починайте з fancy-інструментів. Починайте з питання: чи можу я точно сказати, яка частина користувачів отримує нову версію, і чи можу я швидко повернути їх назад?

3. Домовтесь про метрики до старту

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

error rate не вищий за стабільну версію;
latency не зростає понад узгоджений поріг;
немає нового типу критичних помилок у логах;
ключові бізнес-події не падають;
ресурси сервісу не йдуть у стелю.

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

4. Почніть з малого traffic split

Для ризикової зміни стартуйте з 1% або навіть з внутрішніх користувачів. Для простішої зміни можна почати з 5% чи 10%. Але не робіть перший крок занадто великим, якщо rollback не перевірений.

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

5. Тримайте rollback поруч

Rollback має бути готовим до старту rollout, а не після першого інциденту. Команда має знати:

яку команду або кнопку натиснути;
хто приймає рішення;
як перевірити, що трафік повернувся на стабільну версію;
що робити з даними, які вже обробила canary-версія.

Якщо rollback займає годину ручної магії, canary release все одно зменшить ризик, але не настільки, як хочеться.

6. Запишіть release log

Короткий release log дуже допомагає. Достатньо зафіксувати час старту, версію, traffic split, метрики, рішення і час завершення. Коли через два тижні хтось питатиме, чому rollout зупинили на 25%, відповідь буде не в пам’яті однієї людини.

Антипатерни

називати реліз canary release, але перемикати одразу 50% трафіку без причини;
не мати стоп-умов і сперечатися про метрики під час rollout;
дивитися тільки на середню latency і не бачити хвости;
запускати canary без швидкого rollback;
викочувати зміну з незворотною міграцією бази даних без плану сумісності;
використовувати feature flag, але не видаляти старі прапорці після стабілізації;
вважати staging зайвим, бо “canary все зловить”;
не попереджати підтримку або чергового інженера про ризиковий реліз.

Висновок / План дій

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

Що зробити далі:

вибрати зміну, яку можна відкривати поступово;
перевірити, що staging і deploy pipeline уже працюють;
підготувати traffic split або feature flag;
записати метрики і стоп-умови;
перевірити rollback;
почати з малого відсотка;
вести release log до повного rollout або зупинки.

Якщо після цього реліз звучить трохи менш героїчно - це хороший знак. Production любить нудні, повторювані кроки.

Офіційні джерела:

Короткий чеклист

Перевір, що одна і та сама версія пройшла staging і готова до production.
Визнач перший малий traffic split і наступні кроки rollout.
Домовся про метрики, стоп-умови і відповідального за рішення.
Переконайся, що rollback працює швидше, ніж проблема розростається.
Не починай canary release без моніторингу і короткого release log.

Prompt Pack: спланувати canary release

Допоможи спланувати canary release для сервісу перед production-релізом. Вхідні дані: - що саме змінюється: frontend, API, worker, база даних або інфраструктура; - поточний deploy pipeline і чи є staging; - як зараз перемикається трафік між версіями; - які метрики доступні: error rate, latency, saturation, бізнес-події; - чи є feature flag; - як швидко можна зробити rollback. Поверни: 1. чи підходить canary release для цієї зміни; 2. безпечний traffic split по кроках; 3. які метрики дивитися на кожному кроці; 4. коли зупиняти rollout; 5. rollback-план; 6. короткий чек-лист перед стартом. Формат відповіді: verdict, план rollout, метрики, стоп-умови, rollback, чек-лист.