AI ассистенты уже просто вошли в процессы разработки кода, но что на счет DevOps задач и CI/CD в частности? Думаю здесь их полезность может оказаться не чуть не меньше.
Как часто к вам или вы прибегали с круглыми глазами и просьбами помочь с упавшим пайплайном?
Как бы получить ответ быстро не заставляя никого заниматься скучной однообразной работой? Изучать логи джобы и искать в описании пайплайна ошибку, сравнивать что успели сломать с последнего коммита и так далее.
К счастью теперь за нас это могут нейросети и давать дельные советы (не все, но могут)
Что нужно продумать заранее
Прежде чем писать код, стоит ответить на четыре вопроса. Они определят архитектуру всего решения.
Какие события запускают анализ? В нашем случае — не успешно завершённая джоба в CI/CD. Для начала диагностики достаточно передать агенту последние 50 строк лога сборки и содержимое pipeline-файла.
Какие источники данных понадобятся? Основные — система контроля версий (доступ к репозиториям), CI/CD (полный лог, связанные джобы), инструмент проверки доступности эндпоинтов и метрики потребления ресурсов CI-агентами.
Чтобы создать такого инженера для начала необходимо определиться:
Какие события и в каком формате предоставлять инженеру?
Какие источники и данные могут понадобиться?
Как манипулировать этими данными, чтобы определить корень проблемы?
Каким будет результат диагностики по форме и содержанию?
Как анализировать данные? Это самая интересная часть, потому что вариантов много и они зависят от типа джобы:
Джобы сборки — проблемы с зависимостями (отсутствуют, неправильно указаны, недоступны), ошибки в коде, недостаток ресурсов для сборки.
Джобы тестов — ошибки в коде, неверно написанные тесты.
Джобы деплоя — ошибки в манифестах, проблемы на стороне целевой платформы.
Общие проблемы — ошибки в самом pipeline/workflow, отсутствие утилит на агенте, проблемы с инициализацией агентов.
Каким будет формат отчёта? Чаще всего такой отчёт читают глазами в чате, поэтому он должен быть написан живым языком. Сжато, только факты: что обнаружено, наиболее вероятные причины, конкретные шаги для исправления. Удобное место для отчёта — тред под сообщением об ошибке или специальный канал.
Архитектура решения
В общих чертах флоу работает так: поступает событие об успешном окончании джобы. Далее мы запрашиваем данные для проведения анализа: логи сборки, описание пайплайна. На основе этих данных и своего системного промта AI agent производит разбор падения. В процессе анализа ассистент может самостоятельно проверить репозиторий, что менялось и так далее. В случае ошибок недоступности внешних эндпоинтов проверить это. При неудачном деплое проверить логи и метрики приложения. В результате генерируется несколько наиболее вероятных причин сбоя и способов устранения. Эти данные затем отправляются в командный чат.
Пора переходить к реализации
Некоторые аспекты реализации более подробно рассмотрены в этой статье
n8n - быстро запустить n8n с необходимыми mcp вы можете с помощью docker-compose
Настройка входящих событий
Первый шаг — создать webhook в n8n. Gitlab для аутентификации использует заголовок X-Gitlab-Token, поэтому в n8n выбираем Header Auth и указываем соответствующий credential.
В Gitlab настраиваем отправку вебхуков. Это можно сделать как для отдельного репозитория, так и для целой группы. Указываем адрес webhook и секретный токен, а из типов событий выбираем Pipeline events.
Далее с помощью ноды “if” отсекаем все не failed события, нам они не нужны.
Сбор данных
Как только мы получили событие о падении джобы, запрашиваем из Gitlab подробности.
Для этого потребуется создать gitlab access token (советую только на чтение) и соответствующий credential в n8n
Затем объединяем все полученные данные с помощью ноды Merge.
Анализ ошибок
Данные агенту будут поступать в таком формате
[{ "job_log": "Last 50 lines of failed job" }, {"data": "Content .gitlab-ci.yml"}, {"pipeline": {}}, // information about project and pipeline {"failed_job" {}}, // information about failed job },]
Об этом стоит сообщить агенту заранее. А также об инструментах, которыми он располагает и для чего их использовать.
Даем советы по ведению расследования исходя из сделанных выше соображений. Определяем выходной формат. В качестве модели лучше использовать наиболее свежие, т.к. они лучше справляются с использованием MCP.
Память здесь мы не подключаем, т.к. каждое падение сборки это отдельное событие для агента.
MCP инструменты
Доступные агенту инструменты:
Gitlab-mcp - для получения дополнительной информации об упавшей джобе, изменениях в коде и т.п.
Grafana-mcp - для получения метрик агента, а также логов неудачного деплоя
Http-request - встроенный инструмент для проверки доступности
Важный момент: убедитесь, что ваши MCP-серверы работают в режиме remote. Если какой-то MCP не поддерживает remote из коробки, это можно решить с помощью mcpgateway — он проксирует HTTP в stdin. В качестве транспорта лучше выбрать streaming HTTP.
Отправка в чат
Финальный шаг — отправка сгенерированного отчёта в Slack. Отчёт уходит в выбранный канал или тред.
Тестирование и примеры работы
Итоговый workflow выглядит так. Вы можете импортировать его себе, настроить доступы
Пример разбора упавшего билда
Gradle не может зарезолвить зависимость. Агент определяет, что это проблема с dependency resolution, а не ошибка компиляции. Выдаёт конкретные причины: артефакт не опубликован в репозитории, или credentials недоступны внутри Docker build context. Для каждой причины — шаги для исправления.
Пример ошибки применения инфраструктурных изменений
Terraform plan падает с ошибками
Unsupported argument. Агент распознаёт, что HCL-конфигурация содержит атрибуты, не поддерживаемые текущей схемой провайдера DigitalOcean. Выдаёт три вероятные причины — от неправильного ресурса до версионного рассогласования провайдера — с конкретными шагами исправления для каждой.
Заключение
Мы получили ассистента, который производит анализ ошибок примерно за 30 секунд. Это позволяет более оперативно исправлять упавшие джобы. Это позволяет команде значительно быстрее реагировать на упавшие джобы и тратить своё время на настоящие инженерные задачи, а не на рутинный разбор логов.
Потребление токенов находится на уровне нескольких тысяч токенов
Базовая версия workflow доступна на github
Детали настройки и весь необходимый код для быстрого старта доступен на Boosty
