Команда хочет внедрить canary-деплой как часть стратегии безопасных релизов. Какие метрики и правила нужны, чтобы автоматически решать "продолжить раскатку или откатить"?

Короткий ответ

Нужно сравнивать ключевые метрики (доля ошибок, latency по перцентилям, бизнес-метрики) между canary-версией и стабильной версией на сопоставимом объёме трафика в течение заданного времени, с чёткими порогами отклонения, при превышении которых автоматический откат срабатывает без ожидания человека.

Как это работает подробнее

canary-деплой направляет небольшую долю трафика (например, 5%) на новую версию, оставляя остальной трафик на стабильной версии; сравнение метрик именно между версиями (а не абсолютные пороги) важно, потому что внешние факторы (общий рост нагрузки) влияют на обе версии одинаково, и сравнение показывает именно разницу, вызванную новым кодом.

Пример / кейс

Ожидаемое поведение: если за 15 минут error_rate у canary-версии превышает error_rate стабильной версии более чем на 0.5 процентных пункта, система автоматически откатывает canary до того, как проблема затронет весь трафик, и уведомляет команду с деталями отклонения.

Пример кода

example.yamlКопировать

# Пример правила анализа canary (псевдо-конфигурация)
canary_analysis:
  traffic_split: 5%
  duration: 15m
  metrics:
    - name: error_rate
      max_deviation_from_baseline: 0.5%
    - name: latency_p99
      max_deviation_from_baseline: 20%
  on_failure: automatic_rollback

Что использовать на практике

• Практический подход. Нужно задать минимальный объём трафика/времени для статистически значимого сравнения (слишком маленький canary даст шумные, недостоверные результаты), определить "стоп-метрики" (error rate, latency p99, специфичные бизнес-метрики вроде доли неуспешных платежей) и их допустимое отклонение, и автоматизировать откат при превышении порога без ожидания ручного решения, особенно вне рабочих часов.

Подводные камни

• Частые ошибки. Сравнивать абсолютные значения метрик canary с историческими данными вместо параллельного сравнения с текущей стабильной версией; делать canary слишком маленьким по объёму или времени, что даёт недостоверные (шумные) результаты и либо ложные откаты, либо пропущенные проблемы; не автоматизировать откат, из-за чего проблема обнаруживается человеком с задержкой.