Все кто касался темы обеспечения бесперебойной работы сервисов знает на сколько изнуряющим и трудно оценимым по времени бывает диагностика и устранение инцидентов.

За годы своей работы я наблюдал эволюцию процессов реакции и устранение инцидентов, от кто увидел первым проблему, тот с ней и разбирается, до строго определенных круглосуточных дежурств, сроков реакции, следованию ранбукам и разделениям зон ответственности по платформам.

Одно остается неизменным:

Сбор данных из разных источников
- Метрики
- Логи
- Трэйсы
- Графики релизов и тех. работ
Анализ на основе собственных знаний и опыта
Выработка возможных решений

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

Писать/обновлять runbook под каждый алерт достаточно утомительное занятие, именно поэтому опытный инженер всегда будет эффективней базы из сотен ранбуков.

А что, если функция инженера выполняется, даже когда самого инженера физически нет?

Проектируем ассистента: что нужно определить заранее

Тем кто очень спешит, может мотать вниз, чтобы увидеть итоговую реализацию.

А мы переходим к подготовке. Прежде чем писать код, стоит ответить на четыре вопроса:

Какие события и в каком формате предоставлять агенту?
Какие источники и данные могут понадобиться?
Как манипулировать этими данными, чтобы определить корень проблемы?
Каким будет результат диагностики по форме и содержанию?

Разберем каждый пункт. А ссылку на сам workflow можно найти ниже

События и формат

Как правило достаточным для начала диагностики является событие, в котором описано

Alertname
Description
Labels/Tags
namespace
instance
env
region
Grafana Dashboard
Runbook Url

Источники данных

Наиболее часто мы обращаемся к:

Метрикам, вышедшим за рамки допустимых значений
Метрикам потребления ресурсов и нагрузки
Логам ошибок
Платформе будь то k8s или отдельный сервер
Связанным релизам в CI/CD
Описанию алерта и условия его сработки

Анализ данных

Пожалуй нельзя создать эталонный порядок действий для анализа. Порядок диагностики и анализа имеет вариативность и поэтому еще никто не смог создать скрипт покрывающий все возможные варианты, но мы постараемся.

Прежде всего попытаемся понять, как мы сами подходим к диагностике инцидента.

Смотрим, что происходит с метрикой, по которой сработал алерт, и определяем характер аномалии: спайка, монотонный рост, стабильно критическое значение
Выясняем, программный ли это сбой или он вызван проблемами уровнем ниже
Проверяем метрики инфраструктуры: ресурсы, сеть, системные лимиты
Изучаем логи в точке, где происходит проблема
Определяем, как давно обновлялись проблемные компоненты и что менялось
Пытаемся взаимодействовать с компонентами напрямую — через оркестратор или оболочку Linux

Формат отчета

Чаще всего такой отчет нужно смотреть глазами, поэтому он должен быть написан живым языком. Сжато, только обнаруженные факты, список предположений и возможные исправления. Достаточно удобным место для такого отчета является трэд под соответствующим алертом в командном чате.

Архитектура решения

Перейдем к описанию желаемого флоу. При генерации алерта событие об этом должно отправляться в вебкух, который возьмет из полученных данных и сформирует понятный, ожидаемый для AI агента промт.

AI агент согласно своему системному промту и доступным mcp производит диагностику и генерирует заключение в установленном виде.

Заключение отправляется в командный чат.

Реализация

В качестве среды реализации подобных workflow я выбираю n8n. Так как позволяет

достаточно быстро создавать легко читаемые механики
легко делиться результатами работы
отделять логику от секретов и прочих хардкодов
имеет бесплатную self-hosted версию
огромное комьюнити

Лично мне он напоминает Jenkins лет 10 назад, а Jenkins был хорош. Вы можете установить n8n любым из доступных способов по документации, например через docker-compose

Далее реализация будет зависеть от используемых систем, у меня это

Препроцессинг входящих событий

Alertmanager умеет отправлять алерты на кастомный вебхук. В n8n достаточно создать для этого триггер ноду webhook и можно также указать параметры аутентификации.

Добавить данные о созданном вебхуке в новый receiver n8n в alertmanager

После этого мы сможем отправлять алерты из Alertmanager в наш workflow. Но в получаемых сообщениях есть лишние данные, а также формат не совсем подходящий. Из-за этого LLM будет хуже понимать, что от нее хотят и тратить больше токенов. Поэтому мы делаем небольшое преобразование с помощью Code node.

Вам скорее всего захочется сложить некоторые значения в переменные: например uid вашего Prometheus в Grafana

AI Agent

Обязательным условиям для работы узла AI Agent это подключенная LLM. Можно подключить практически любую нейросеть, но из опыта Codex и Opus справляются лучше всего

Memory мы здесь не используем, т.к. каждый алерт отдельное событие, не связанное с другими.

Одним из важных моментов является написание системного промта. Что стоит там написать?

Назначение Агента
Краткое описание вашей инфраструктуры и типа предоставляемого вами сервиса
Описание для чего нужен каждый MCP, например использовать kubernetes mcp для получения статуса пода, событий связанных с ним и т.д.
Важные правила, которым нужно следовать и чего избегать, например не задавать вопросов, писать ответ на определенном языке, никогда не вносить никаких изменений и т.д.
Рекомендации по ходу диагностики, это как раз то, что мы обсуждали в разделе про Анализ данных

MCP — глаза и уши агента

MCP являются глазами и ушами агента, давая ему возможность взаимодействовать предметом диагностики. Здесь список может варьироваться в зависимости от конкретной инфраструктуры, но основные виды источников данных (которые, мы рассмотрели в начале ) остаются неизменными. В моем случае список выглядит так

Метрики - mcp-grafana
Логи - mcp-grafana
Платформа - kubernetes-mcp, digitalocean-mcp
Релизы в CI/CD - gitlab-mcp
Описание алертов - vector store

При запуске ваших mcp убедитесь, что они работают в режиме remote http streaming

Vector store

Отдельно стоит остановиться на базе знаний. Сюда можно класть большие объемы информации и осуществлять быстрый поиск по ним. Это экономит токены и время на запросы к внешним системам. В качестве такой базы я использую Qdrant. Настоятельно советую задать Service API token для аутентификации

Далее необходимо создать коллекцию, где будут хранится знания. Создать можно через веб интерфейс http://<your-host>:6333/dashboard

Создайте QdrantApi аккаунт и используйте его для подключения.

Как только база подключена к агенту, как tool, самое время загрузить в него знания. Для этого я использую отдельный workflow

Здесь можно загрузить в появившуюся форму ваш файл/файлы со знаниями и они будут сохранены в базу.

Отправка в чат

После того, как AI агент сделает свое дело, нам нужно отправить результаты его работы в чат, где их будут видеть инженеры. Цепочка отправки состоит из 3х узлов,

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

Для отправки взаимодействия со Slack, вам нужно будет настроить аутентификацию по этой инструкции

Тестирование и примеры работы

Итоговый workflow выглядит так.

Я тестировал его небольшие модификации на нескольких проектах и вот, что получилось

В среднем анализ алерта тратится 30 секунд. За это время он успевает посмотреть метрики, логи, обстановку в k8s кластере и дать заключение.

Заключение

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

Это лишь одно из направлений, где AI способен существенно упростить жизнь инфраструктурным командам — и командам разработчиков, которые вынуждены сами заниматься поддержкой. Агент не заменяет инженера, но берёт на себя первичную диагностику и сокращает время от «алерт сработал» до «понятно, в чём дело». А ночью — когда дежурный спит — это может оказаться бесценным.

Базовую версию workflow можно найти тут: https://github.com/javdet/automagicops-workflows/tree/main/workflows/AlertAssistant

Хочешь быстро реализовать похожий flow у себя? Читай полный гайд на Boosty с подробными примерами, практическими советами.

Автор статьи: https://linkedin.com/in/sergeybyvshev

AI-ассистент для алертов: как n8n + LLM