Настройте автоматический откат canary-релиза по метрике ошибок без участия человека. Какие риски нужно учесть при полной автоматизации такого решения?

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

Контроллер прогрессивной доставки (например, Argo Rollouts с AnalysisTemplate на основе Prometheus-запроса error rate) на каждом шаге сравнивает метрику canary-версии с порогом, и при нескольких подряд нарушениях автоматически устанавливает вес canary в 0% и помечает Rollout как Degraded, без ожидания человека; риски — ложные срабатывания из-за шумных метрик или недостаточного объёма трафика, а также отсутствие отката побочных эффектов вне кода (например, уже отправленных внешних вызовов или записанных в БД данных).

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

AnalysisTemplate выполняет PromQL-запрос с заданным интервалом, сравнивает результат с `successCondition`, и при накоплении заданного числа неудачных проверок (`failureLimit`) Rollout-контроллер автоматически откатывает трафик на стабильную версию, останавливая дальнейшее продвижение.

Пример кода

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

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: error-rate-check
spec:
  metrics:
    - name: error-rate
      interval: 1m
      failureLimit: 3
      successCondition: result[0] < 0.01
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            sum(rate(http_requests_total{job="myapp",version="canary",status=~"5.."}[1m]))
            /
            sum(rate(http_requests_total{job="myapp",version="canary"}[1m]))

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

• На практике. автоматический откат эффективен для метрик с чётким и быстрым сигналом (HTTP 5xx rate, задержка), но рискован для метрик с низким объёмом данных (canary на 5% трафика при низком общем RPS даёт статистически шумный результат) — для таких случаев нужно либо увеличивать стартовый процент трафика, либо удлинять интервал анализа. Полностью автоматический откат не решает проблему данных, уже испорченных неудачной версией (например, если canary успела записать некорректные записи в базу) — такие побочные эффекты нужно устранять отдельно.
• Пример. Ожидаемое поведение: если доля 5xx-ответов canary превышает 1% три проверки подряд, Argo Rollouts автоматически останавливает продвижение и возвращает 100% трафика на стабильную версию, что видно в `kubectl argo rollouts get rollout myapp` по статусу `Degraded`.

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

• Частые ошибки. ставят `failureLimit: 1`, из-за чего один случайный всплеск latency откатывает полностью рабочий релиз; не учитывают при автоматизации, что откат трафика не равен откату уже случившихся побочных эффектов (отправленные письма, платежи, записи в очередь).