Автор: Listen IT · Listen IT
Видео Listen IT, 9 минут. Canary deployment и Blue-Green — две стратегии выката, которые решают одну задачу разными способами: как выпускать новые версии без того, чтобы весь трафик сразу шёл на непроверенный код.
Canary deployment — это постепенный выкат: сначала 1–5% пользователей получают новую версию, остальные работают со старой. За это время смотрят на метрики: error rate, latency, конверсии. Если всё хорошо — процент растёт. Если что-то ломается — откатить стоит секунд, а не часов. Название идёт от шахтёрской практики: канарейки чувствовали токсичный газ раньше людей. Небольшой процент пользователей — первые, кто обнаруживает проблему, пока большинство ещё на безопасном коде. Это принципиально другой разговор о надёжности: не “как сделать, чтобы не сломалось”, а “как сделать, чтобы поломка затронула минимум людей и откатилась быстро”.
Кому смотреть: разработчикам и DevOps-инженерам, у которых релиз — это страшное событие раз в неделю с ручным smoke-тестингом. И тем, кто хочет перейти к continuous delivery, но не понимает, с чего начать с точки зрения безопасности выката.
Из этого можно взять в работу: посмотрите на последний релиз в вашей системе. Сколько времени заняло бы обнаружение проблемы, если бы она появилась? Если больше 15 минут — у вас нет canary, и риск каждого релиза выше, чем должен быть.
Canary vs Blue-Green: ключевое различие в том, как работает трафик. Blue-Green держит две полные копии среды (синюю — старая версия, зелёную — новая), переключение трафика мгновенное. Это хорошо для атомарных релизов, где нужно быстро переключиться и откатиться. Canary не переключает весь трафик сразу — он размазывает риск во времени и даёт статистику на реальных пользователях.
Шаги реализации Canary: развернуть новую версию на отдельных инстансах, настроить маршрутизацию (через load balancer, service mesh или feature flags) так, чтобы малый процент запросов шёл на новые инстансы, наблюдать за метриками, постепенно увеличивать процент или откатывать.
Что наблюдать во время Canary: error rate (должен быть не хуже стабильной версии), latency (P99 особенно важен), бизнес-метрики (конверсия, отказы, активность) — технические метрики могут быть ок, а бизнес страдать. Именно комбинация технических и бизнес-метрик делает canary реально работающим инструментом.
Ограничения: canary плохо работает при несовместимых изменениях схемы базы данных — когда новая и старая версия не могут работать с одними данными одновременно. Это отдельная инженерная задача: expand/contract миграции, версионирование API. Canary сам по себе не решает database migration, но хорошо сочетается с правильно выстроенными миграциями.