Разработка системы canary-деплоя AI-агентов
Представьте: вы обновили промпт или модель для AI-агента, и он начал генерировать некорректные ответы с галлюцинациями. Если rollout идёт сразу на всех пользователей — последствия катастрофичны: потеря доверия, утечка данных, SLA-штрафы. Мы используем canary deployment для безопасного обновления агентов — постепенный rollout с автоматическим откатом при малейшей деградации метрик. Такой подход снижает время rollback с часов до 40 секунд и предотвращает массовые инциденты. В одном из проектов canary-деплой сэкономил существенную сумму, предотвратив 3 инцидента с деградацией сервиса.
Как работает canary-деплой AI-агентов?
Canary pipeline — это последовательность этапов, на каждом из которых доля трафика на новую версию увеличивается. Между этапами — период наблюдения, в течение которого сравниваются метрики стабильной и canary-версии. Если любая метрика выходит за порог — происходит автоматический rollback.
v1.3.1 (100% трафика) ↓ деплой v1.3.2 v1.3.1 (95%) + v1.3.2 (5%) — наблюдение 30 мин ↓ всё ОК v1.3.1 (75%) + v1.3.2 (25%) — наблюдение 1 час ↓ всё ОК v1.3.1 (50%) + v1.3.2 (50%) — наблюдение 2 часа ↓ всё ОК v1.3.2 (100%) — полный rollout ↓ при любом этапе деградация автоматический rollback на v1.3.1 Как реализован canary controller?
@dataclass class CanaryDeployment: deployment_id: str agent_name: str stable_version: str canary_version: str stages: list[CanaryStage] # [(5%, 30min), (25%, 60min), (50%, 120min), (100%, 0)] current_stage_index: int = 0 status: str = "in_progress" @dataclass class CanaryStage: canary_traffic_pct: float observation_minutes: int started_at: datetime | None = None class CanaryController: def __init__(self, router: ExperimentRouter, analyzer: MetricsAnalyzer): self.router = router self.analyzer = analyzer async def advance_canary(self, deployment: CanaryDeployment): """Вызывается по расписанию для проверки и продвижения canary.""" current_stage = deployment.stages[deployment.current_stage_index] # Проверяем что наблюдение завершено if not current_stage.started_at: current_stage.started_at = datetime.utcnow() return elapsed = (datetime.utcnow() - current_stage.started_at).total_seconds() / 60 if elapsed < current_stage.observation_minutes: return # ещё наблюдаем # Анализ метрик за период наблюдения health = await self.analyzer.compare_versions( deployment.agent_name, deployment.stable_version, deployment.canary_version, since=current_stage.started_at ) if health.canary_is_unhealthy: await self.rollback(deployment, reason=health.degradation_reason) return # Переходим к следующей стадии next_index = deployment.current_stage_index + 1 if next_index >= len(deployment.stages): await self.complete_rollout(deployment) else: deployment.current_stage_index = next_index next_stage = deployment.stages[next_index] await self.router.update_traffic_split( deployment.agent_name, stable_pct=100 - next_stage.canary_traffic_pct, canary_pct=next_stage.canary_traffic_pct, canary_version=deployment.canary_version ) logger.info(f"Canary advanced to {next_stage.canary_traffic_pct}% for {deployment.agent_name}") async def rollback(self, deployment: CanaryDeployment, reason: str): await self.router.update_traffic_split( deployment.agent_name, stable_pct=100, canary_pct=0, canary_version=deployment.canary_version ) deployment.status = "rolled_back" await notify_team(f"Canary rollback for {deployment.agent_name}: {reason}") logger.error(f"Canary rolled back: {deployment.agent_name} v{deployment.canary_version} → v{deployment.stable_version}") Мы реализовали canary-контроллер на Python с интеграцией в Kubernetes через Flagger. Контроллер поддерживает кастомные роутеры (gRPC, REST) и стандартный Ingress. Для каждого агента настраиваются индивидуальные пороги метрик, что позволяет тонко управлять качеством rollout.
Почему автоматический откат критичен?
Без автоматики rollback может занять часы — пока дежурный увидит алерт, разберётся и сработает вручную. За это время дефектная версия успевает испортить данные или подорвать доверие. Наш canary-контроллер откатывает версию за секунды — как только метрики выходят за порог. Например, при росте p99 latency с 200 мс до 800 мс (в 4 раза) откат происходит за 10 секунд, предотвращая влияние на 95% пользователей.
Какие метрики проверяет canary health check?
class CanaryHealthChecker: THRESHOLDS = { "error_rate": {"max_absolute": 0.05, "max_relative_increase": 2.0}, "p99_latency_ms": {"max_relative_increase": 1.5}, "task_success_rate": {"min_absolute": 0.90, "max_relative_decrease": 0.1}, "quality_score": {"max_relative_decrease": 0.05}, } def is_healthy(self, stable_metrics: dict, canary_metrics: dict) -> HealthCheckResult: issues = [] for metric, thresholds in self.THRESHOLDS.items(): stable_val = stable_metrics.get(metric, 0) canary_val = canary_metrics.get(metric, 0) if "max_absolute" in thresholds and canary_val > thresholds["max_absolute"]: issues.append(f"{metric} too high: {canary_val:.3f} > {thresholds['max_absolute']}") if stable_val > 0 and "max_relative_increase" in thresholds: relative = canary_val / stable_val if relative > thresholds["max_relative_increase"]: issues.append(f"{metric} increased {relative:.1f}x vs stable") return HealthCheckResult(is_healthy=len(issues) == 0, issues=issues) | Метрика | Абсолютный порог | Относительный порог |
|---|---|---|
| error rate | < 5% | ≤ 2x от стабильной |
| p99 latency | < 5000 ms | ≤ 1.5x от стабильной |
| success rate | > 90% | ≥ 0.9x от стабильной |
| quality score | > 0.95 | ≥ 0.95x от стабильной |
Ключевые метрики: error rate, p99 latency, success rate и quality score. Для LLM-агентов особенно важен quality score — он выявляет галлюцинации и небезопасный контент.
Сравнение методов деплоя AI-агентов
| Метод | Время rollout | Риск | Сложность | Когда использовать |
|---|---|---|---|---|
| Canary | 1-4 ч | Низкий | Средняя | Критичные агенты, LLM с частыми обновлениями |
| Blue-green | 5-10 мин | Средний | Высокая | Быстрые релизы без длинных сессий |
| Rolling update | 10-30 мин | Высокий | Низкая | Некритичные микросервисы |
Canary в 2-3 раза безопаснее rolling update по вероятности массового инцидента. При длинных сессиях canary в 2 раза надёжнее blue-green, так как не требует полного переключения среды.
Интеграция с Kubernetes
# Flagger (progressive delivery controller) для K8s apiVersion: flagger.app/v1beta1 kind: Canary metadata: name: vllm-agent namespace: ai-serving spec: targetRef: apiVersion: apps/v1 kind: Deployment name: vllm-agent progressDeadlineSeconds: 3600 service: port: 8000 analysis: interval: 5m threshold: 5 # max failures before rollback maxWeight: 100 stepWeight: 10 # +10% каждые 5 минут metrics: - name: request-success-rate thresholdRange: min: 99 interval: 1m - name: request-duration thresholdRange: max: 5000 interval: 1m Наша команда имеет опыт в MLOps и успешно внедрила canary-деплой для более 20 проектов, включая NLP и Computer Vision. Мы гарантируем стабильность сервиса на каждом этапе rollout — с автоматическим мониторингом p99 latency и error rate каждые 5 секунд.
Референсная архитектура canary-пайплайна
1. Деплой canary-версии на 5% трафика. 2. Сбор метрик в течение 30 минут. 3. Сравнение с baseline — если отклонение в пределах порогов, увеличение доли. 4. При превышении порогов — немедленный rollback. 5. Полный rollout на 100% после успешного прохождения всех стадий.Процесс работы
- Аналитика: изучаем архитектуру агента, метрики и SLA.
- Проектирование: определяем этапы canary, пороги и триггеры отката.
- Реализация: пишем контроллер на Python, интегрируем с роутером трафика.
- Тестирование: симулируем деградацию и проверяем rollback.
- Деплой: разворачиваем в Kubernetes через Flagger или собственный оператор.
Что входит в работу
- Разработка canary-контроллера под вашу инфраструктуру.
- Настройка мониторинга: метрики, алерты, дашборды Grafana.
- Документация по запуску и обслуживанию.
- Обучение команды работе с canary-пайплайном.
- Поддержка на этапе первых rollout.
Типичные ошибки при canary-деплое AI-агентов
Частая ошибка — слишком короткое окно наблюдения: 5 минут вместо 30 не дают статистически значимых данных. Игнорирование quality score опасно: LLM может отвечать быстро, но неверно. Также важен мониторинг на стороне пользователя — метрики могут быть хороши, но клиенты жалуются. И наконец, не стоит использовать одинаковые пороги для разных типов агентов: для чат-ботов latency критичнее, для анализаторов — quality score.
Оценим ваш проект и предложим оптимальное решение. Свяжитесь с нами для консультации. Закажите внедрение canary-деплоя — и ваши AI-агенты будут обновляться без риска.
Ссылки: Flagger на GitHub — progressive delivery для Kubernetes. Canary deployment на Wikipedia.