От обычных гейтов в CI/CD к Agentic CI/CD с MCPКлассический цикл «Build-Push-Deploy» прост только на бумаге. В реальности мы регулярно упираемся в проблему: пайплайн отработал идеально, тесты прошли, артефакт собран… и релиз улетает в кластер, который прямо сейчас находится под высокой нагрузкой (Memory pressure, CPU throttling или риски OOM).
Обычно эту проблему решают написанием громоздких bash/python-скриптов или запросов к API Prometheus, которые проверяют Deployment Gates. Но эти скрипты жесткие, хрупкие и требуют постоянного обслуживания.
На смену им приходит Agentic CI/CD — подход, где роль гейткипера перед деплоем выполняет AI-агент, взаимодействующий с инфраструктурой через Model Context Protocol (MCP).
Как это работает на практике?
Вместо выполнения захардкоженного скрипта GitHub Actions обращается к Elastic MCP Server и запрашивает статус кластера на понятном языке.
Сбор метрик: OpenTelemetry Collector непрерывно собирает данные о состоянии Kubernetes-кластера.AI-агент: в Elastic создается специализированный Observability Kubernetes Agent с системными инструкциями и кастомными ES|QL-инструментами для анализа ресурсов.Запрос из CI/CD: GitHub Actions через MCP-протокол отправляет агенту промпт:«Скажи, использует ли кластер otel-test более 25% CPU или памяти на любом из узлов?»
Принятие решения: агент запрашивает метрики, находит просадку, форматирует понятный отчет и отдаёт статус. Если кластер нестабилен — пайплайн автоматически падаёт до этапа синхронизации в ArgoCD/Flux.Зачем это нужно?
Вы не тратите ресурсы на выкатку релиза в падающий или перегруженный кластер. Агент может учитывать сразу комплекс факторов (метрики, активные алерты, динамические пороги), а не просто сверять одну статичную цифру. В логах CI/CD остается не безымянный exit code 1, а человекочитаемый разбор от агента с указанием конкретной ноды и метрик.@DevOpsKaz
