Все кто касался темы обеспечения бесперебойной работы сервисов знает на сколько изнуряющим и трудно оценимым по времени бывает диагностика и устранение инцидентов.
За годы своей работы я наблюдал эволюцию процессов реакции и устранение инцидентов, от кто увидел первым проблему, тот с ней и разбирается, до строго определенных круглосуточных дежурств, сроков реакции, следованию ранбукам и разделениям зон ответственности по платформам.
Одно остается неизменным:
Сбор данных из разных источников
Метрики
Логи
Трэйсы
Графики релизов и тех. работ
Анализ на основе собственных знаний и опыта
Выработка возможных решений
Если у вас есть инструкция, что делать в каждой ситуации - это немного упрощает дело, но не учит образу мышления необходимого для расследования и устранения.
Писать/обновлять 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
