Когда ваш пайплайн принимает решения: автоматизация прогрессивной доставки

Представьте: 2 часа ночи субботы. Ваша команда запустила релиз перед уходом домой. Новая версия начинает получать 5% продакшн-трафика. Через пять минут уровень ошибок начинает расти. Никто не смотрит в дашборд. К тому времени, как кто-то проверит телефон утром, пользователи уже несколько часов сталкиваются с ошибками.

Этот сценарий встречается чаще, чем многие команды готовы признать. Релизы не всегда происходят в рабочее время. У команд есть жизнь вне работы. И ожидание, пока человек заметит проблему, прежде чем принять меры, создает ненужные простои.

Решение — не держать людей на дежурстве вечно. А дать вашему пайплайну возможность принимать решения самостоятельно.

Как работает автоматическое гейтинг

Основная идея проста. Пайплайн прогрессивной доставки состоит из нескольких этапов, каждый из которых направляет на новую версию все больше трафика. Между этапами находится шлюз (gate). Этот шлюз проверяет метрики в реальном времени на соответствие заданным порогам, прежде чем решить, что делать дальше.

Вот конкретный пример. Ваш пайплайн начинает с направления 5% трафика на новую версию. Он ждет пять минут, чтобы накопить данные. Затем проверяет три вещи:

  • Уровень ошибок для новой версии ниже 0.1%?
  • Задержка (latency) в пределах 10% от базовой линии старой версии?
  • Нет ли значительного роста ответов с кодом 5xx?

Если все метрики проходят, пайплайн переходит к следующему этапу, например, расширяет трафик до 20%. Если метрики не проходят, пайплайн должен решить, что делать.

Следующая блок-схема иллюстрирует логику принятия решений на каждом шлюзе пайплайна:

flowchart TD A([Start: 5% traffic]) --> B[Wait 5 min for data] B --> C{Check metrics} C -->|All pass| D[Continue to 20%] C -->|Warning threshold| E[Hold - notify team] C -->|Critical threshold| F[Rollback to old version] D --> G[Wait 5 min] G --> H{Check metrics} H -->|All pass| I[Continue to 50%] H -->|Warning| J[Hold - notify team] H -->|Critical| K[Rollback] I --> L[Wait 5 min] L --> M{Check metrics} M -->|All pass| N[Continue to 100%] M -->|Warning| O[Hold - notify team] M -->|Critical| P[Rollback]

Вот как может выглядеть конфигурация такого шлюза в YAML-пайплайне:

gates:
  - name: canary-5pct
    traffic: 5%
    wait: 5m
    checks:
      - metric: error_rate
        query: "sum(rate(http_requests_total{version='new', status=~'5..'}[5m])) / sum(rate(http_requests_total{version='new'}[5m]))"
        warning: 0.005
        critical: 0.02
        action_warning: hold
        action_critical: rollback
      - metric: latency_p99
        query: "histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{version='new'}[5m])) by (le))"
        baseline: "histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{version='old'}[5m])) by (le))"
        warning: 1.10
        critical: 1.25
        action_warning: hold
        action_critical: rollback

Эта конфигурация проверяет две метрики через пять минут при 5% трафика. Если уровень ошибок превышает 0.5% (warning), пайплайн останавливается. Если превышает 2% (critical), выполняется откат. Задержка сравнивается с базовой линией старой версии с аналогичными порогами.

Три возможных действия: продолжить, остановить или откатить

Как только метрика превышает порог, у пайплайна есть три варианта.

Продолжить — значит, все хорошо. Новая версия переходит на следующий уровень трафика. Это счастливый путь, не требующий вмешательства человека.

Остановить — пайплайн прекращает продвижение релиза, но новая версия продолжает работать на текущем проценте трафика. Команда получает уведомление и может провести расследование без давления. Это полезно, когда проблема еще не критична. Возможно, уровень ошибок немного вырос, но не вызывает тревоги. Команда может проверить логи, трейсы и решить, продолжать или откатывать.

Откатить — пайплайн немедленно переключает весь трафик обратно на старую версию. Это происходит, когда метрики указывают на серьезную проблему. Резкий скачок ошибок. Все запросы начинают падать. Задержка выходит за допустимые пределы. В таких случаях ожидание одобрения человека только усугубляет ситуацию.

Настройка порогов: Warning vs Critical

Решение между остановкой и откатом зависит от серьезности. Многие команды реализуют два уровня порогов.

Порог Warning вызывает остановку. Например, если уровень ошибок достигает 0.5%, пайплайн прекращает продвижение и уведомляет команду. Новая версия остается на текущем уровне трафика, пока кто-то проводит расследование.

Порог Critical вызывает автоматический откат. Если уровень ошибок достигает 2%, пайплайн немедленно отзывает новую версию. Без ожидания. Без вопросов.

Такой двухуровневый подход дает командам пространство для маневра при незначительных проблемах, защищая пользователей от серьезных сбоев. Конкретные числа зависят от толерантности вашего приложения к ошибкам. Платежная система может иметь гораздо более строгие пороги, чем контентный сайт.

Что нужно пайплайну для принятия решений

Автоматическое принятие решений требует совместной работы трех компонентов.

Во-первых, ваша система observability должна предоставлять метрики в реальном времени. Пайплайну нужно запрашивать уровень ошибок, задержку и другие сигналы сразу после переключения трафика. Если ваш мониторинг имеет пятиминутную задержку, пайплайн не сможет принимать своевременные решения.

Во-вторых, пайплайну нужно сравнивать метрики новой версии с базовой линией старой версии. Это означает хранение базовых данных от предыдущего стабильного релиза. Сравнение должно учитывать нормальные колебания. Увеличение задержки на 5% в часы пик может быть нормой, тогда как такое же увеличение при низком трафике может указывать на проблему.

В-третьих, вам нужны четкие правила, закодированные в конфигурации пайплайна. Эти правила определяют, какие метрики проверять, какие пороги использовать и какие действия предпринимать для каждого уровня порога. Держите эти правила простыми и явными. Сложная логика с множеством условий становится трудно поддерживаемой и отлаживаемой.

Автоматизация не заменяет людей

Может показаться, что автоматические решения позволяют полностью игнорировать релизы. Это не так. Автоматизация обрабатывает предсказуемые сценарии. Люди по-прежнему должны:

  • Определять подходящие пороги для каждой метрики
  • Проверять, остаются ли пороги актуальными по мере развития приложения
  • Обрабатывать крайние случаи, которые не покрывает автоматизация
  • Расследовать остановки и решать, продолжать или откатывать
  • Обновлять правила при появлении новых паттернов отказов

Думайте об автоматизации как о страховочной сетке для типичных случаев. Она быстро ловит очевидные проблемы, давая людям больше времени для сложных ситуаций, требующих контекста и суждений.

Краткий практический чек-лист

Перед внедрением автоматических шлюзов принятия решений проверьте основы:

  • Может ли ваш пайплайн запрашивать метрики из системы мониторинга в реальном времени?
  • Есть ли у вас базовые метрики от текущей стабильной версии?
  • Определили ли вы пороги warning и critical для уровня ошибок, задержки и ответов 5xx?
  • Есть ли у пайплайна механизм остановки продвижения без отката?
  • Настроены ли уведомления для нужных людей при остановке или откате?
  • Тестировали ли вы автоматический откат в стейджинге?

Что дальше

Когда ваш пайплайн сможет решать, продолжать, останавливать или откатывать, следующим шагом будет выбор способа распределения трафика. Два распространенных подхода — canary-релизы и поэтапные развертывания. У каждого свои характеристики для расширения охвата новой версии. Правильный выбор зависит от архитектуры вашего приложения и того, как ваша инфраструктура обрабатывает маршрутизацию трафика.

Но это тема для отдельной статьи. А пока сосредоточьтесь на том, чтобы дать вашему пайплайну возможность принимать решения, когда никто не смотрит. Ваши пользователи скажут спасибо, а ваша команда будет спать спокойнее.