Как научить ИИ разгребать метрики, пока дежурный допивает чай

Конспект доклада про ИИ-агента для разбора инцидентов с первого занятия «Вечерней школы. ИИ для инженеров: польза и риски» от Слёрма

Три часа ночи. Телефон вибрирует так, будто сам поймал алерт. Ты открываешь глаза, а вместе с ними десяток вкладок: Grafana, Kibana, три чата в Telegram и Zoom, в который пока никто не зашёл. Знакомая картина? Тогда ты, скорее всего, дежурный инженер, и этот текст для тебя.

Этим летом Слёрм запустил бесплатную «Вечернюю школу. ИИ для инженеров: польза и риски». Шесть открытых онлайн занятий о том, где искусственный интеллект реально помогает инженеру, а где создаёт новые риски. Занятия построены на живых кейсах и рабочих процессах: инженеры, архитекторы, безопасники и даже юрист разбирали, как ИИ встраивается в разбор инцидентов, автофикс прода, SOC и code review, на разных моделях и инструментах.

Первое занятие прошло 21 июля 2026 года и досталось той самой боли, которую хоть раз проходил каждый дежурный: первым минутам инцидента, когда алерты сыплются один за другим, а понять, что вообще происходит, ещё нельзя.

Доклад прочитал Сергей Тимиряев (@sergeytimiryaev на Хабре), человек с опытом в крупных e-commerce-компаниях, банках и небольших зарубежных стартапах. Сергей рассказал, как в одиночку за полгода собрал систему, которая берёт на себя рутинный сбор контекста инцидента, и показал её работу вживую на демо-кластере. Спойлер: сделал он это не ради интереса к коду, а потому что здорово устал в три часа ночи объяснять коллегам по телефону, что вообще происходит с нодой.

Спикер: Сергей Тимиряев

• DevOps и MLOps

• занимается построением отказоустойчивой инфраструктуры

• владелец проектов по автоматизации DevOps и мониторингу

  

Дальше в статье: та боль, с которой всё началось, архитектура решения, разбор промпта, демо, ответы на вопросы аудитории и разбор частых вопросов про ИИ-агентов в мониторинге.

Коротко о докладе, если ты дежурный инженер и время дороже золота

• ИИ-агент из двух частей, Data Enricher и AI Worker, автоматически собирает контекст инцидента: метрики из Prometheus, состояние подов и нод в Kubernetes, свежие деплои и рестарты

• AI Worker передаёт обогащённый алерт в языковую модель через OpenRouter и публикует готовую гипотезу причины прямо в Telegram, реплаем на исходный алерт

• решение сокращает MTTA, время до подтверждения инцидента, с 20 до 30 минут ручного разбора до одной-двух минут, а часто и до секунд

• финальное решение всегда принимает инженер: агент не заходит в прод, не удаляет ресурсы и работает в Kubernetes API только на чтение

• Сергей Тимиряев собрал систему самостоятельно за полгода и выложил проект в открытый доступ на GitHub

Боль: первые 30 минут инцидента

Сергей начал не с решения, а с ситуации, которую легко узнает любой, кто хоть раз был на дежурстве.

Прилетает алерт, который ни на что не похож. Ты честно проверяешь мониторинг: вроде бы всё настроено, шум отфильтрован. Но откуда-то берётся ещё один алерт, с другого сервиса и другой ноды. Кажется, что между ними есть связь, но доказать это можно только одним способом: перелопатить десяток дашбордов, сотню графиков и на ходу вспомнить синтаксис PromQL, чтобы проверить очередную гипотезу.

Дальше ты открываешь инцидент, собираешь звонок, начинаешь вести заметки для будущего постмортема. И тут выясняется, что прошло уже минут двадцать, а большая часть этого времени ушла не на исправление, а на подтверждение самого факта проблемы: подключения по SSH, describe подов и нод, чтение логов. Алерты продолжают сыпаться «оползнем», картина постепенно расширяется, и только к получасовой отметке становится ясно, кому вообще звонить: дежурному DBA, сетевику или разработчику, который в это время в отпуске.

По словам Сергея, полчаса неведения для любого бизнеса уже серьёзная проблема, независимо от того, насколько хорошо настроен мониторинг сам по себе. Более того, даже идеально настроенный мониторинг (отказоустойчивая Grafana, шаблоны алертов с ранбуками, расписания дежурств) не спасает от главного дефицита: он показывает, что горит, но не объясняет, почему это горит и что происходит вокруг.

Мы видим алерты, мы реагируем, мы делаем звонки, всё по правилам. Но не можем ответить на вопрос быстро: что случилось и почему это случилось.

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

Идея: агент повторяет действия инженера, но за секунды

Ключевой принцип, который Сергей проговорил ещё до архитектуры и держал в фокусе весь доклад: агент не думает за инженера и не принимает решений. Его задача в том, чтобы к моменту, когда инженер открывает ноутбук, собрать ровно ту же картину, которую инженер собрал бы сам руками: посмотреть в Prometheus метрики до и после события (память, CPU, диск), заглянуть в Kubernetes API за состоянием пода и ноды, проверить рестарты, OOM-killer, свежие деплои.

Разница только в том, что агент делает это не последовательно и не под давлением ночного звонка, а параллельно и за несколько секунд. Дальше он складывает всё в один обогащённый алерт и просит модель написать черновик разбора: что похоже на причину и что стоит проверить в первую очередь. Именно черновик и гипотезу, а не приговор: финальное решение остаётся за инженером.

Архитектура ИИ-агента для мониторинга: обычная инженерная цепочка

Схема, которую показал Сергей, держится на промпте: вся «интеллектуальность» сосредоточена именно в нём, а остальные элементы представляют собой обычную инженерную цепочку из четырёх звеньев.

Data Collection. В роли источников выступает вся инфраструктура: кластеры Kubernetes, отдельные ноды вне кластера, обычный стек мониторинга (Prometheus, Alertmanager, при необходимости Zabbix). В сам мониторинг система ничего не привносит и ничего не меняет.

Alert Manager → Data Enricher. Когда Alertmanager генерирует алерт, происходят две вещи параллельно: сырое сообщение сразу летит в Telegram, а копия алерта уходит в сервис обогащения под названием Data Enricher.

Data Enricher. Это, по словам Сергея, «сердце системы»: компонент, который автоматически собирает контекст вокруг алерта, ту самую работу, которую раньше он выполнял руками в три часа ночи. Enricher не ждёт, пока ему принесут данные, а сам идёт за контекстом: ходит в Prometheus за метриками за настраиваемый интервал до события (обычно от 10 до 15 минут), в Kubernetes API за состоянием пода и ноды. Обогащается всё, что вообще попадает в мониторинг, включая ноды вне кластера.

Собранные данные раскладываются по ключам: например, если нода находится под давлением по памяти, это явно помечается ключом node.memory.pressure. Это не техническая деталь для галочки: этот же ключ отдельно используется в промпте на следующем шаге, чтобы модель не гадала, а действовала по заранее заданному правилу.

Отдельно Сергей проговорил вопрос безопасности: в прод-кластер Enricher ходит в API только на чтение и с таймаутом. Если Kubernetes API не отвечает за пару секунд, обогащение продолжается без него, и поток инцидентов не блокируется.

AI Worker. Берёт обогащённый алерт, подставляет его в промпт, вызывает модель через OpenRouter и публикует ответ в Telegram реплаем на исходное сообщение с сырым алертом. Важная деталь архитектуры: Alertmanager вообще ничего не знает про LLM и Telegram, он просто отправляет вебхук. Это значит, что если модель или OpenRouter недоступны, сырой алерт всё равно долетит до дежурного. ИИ здесь не становится дополнительной точкой отказа.

Что на самом деле написано в промпте

Сергей специально разобрал промпт AI Worker. По его словам, вся «магия» системы умещается всего в 14 строк.

Модели явно перечисляют, что она получает на входе: метрики с трендами, статусы, состояние. Дальше задаётся жёсткий формат ответа. Вместо свободного сочинения модель должна выдать три конкретных блока: первопричина, рекомендации по исправлению (вплоть до конкретных команд kubectl) и профилактика.

Именно здесь используются подготовленные ключи вроде node.memory.pressure. Модели не нужно догадываться, что делать с давлением по памяти, потому что в промпте прямо прописано правило под этот сигнал.

Модель не угадывает на пустом месте. Мы заранее ей сказали: если это есть, делай вот так. Никакого секрета «прикрутили ИИ, и он стал умным». Это чистая инженерная логика: мы подготовили сигналы и задали правила.

Последнее ограничение в промпте касается объёма: ответ не длиннее 250 слов, без пересказа сырых цифр. Задача в том, чтобы получить короткий разбор, а не «простыню с сочинениями» в чате с алертами.

Как это выглядит на практике: было и стало

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

В системе Сергея тот же алерт получает реплай той же секундой позже: первопричина, конкретные шаги с реальным именем ноды (это подтверждает, что агент действительно сходил и собрал данные) и профилактические рекомендации.

Демо на живом кластере

Чтобы показать, что речь не про слайды, а про работающую систему, Сергей развернул демо-стенд на приложении Sock Shop, том самом, с которого он когда-то начинал знакомство с Kubernetes. Несколько микросервисов, живой трафик от генератора нагрузки, обычный стек мониторинга.

На стенде он «уронил» базу данных каталога: сам сервис оставался жив, но не мог достучаться до своей БД и начинал отдавать 500-е ошибки. Алерты полетели один за другим в реальном времени, и это были не синтетические curl-запросы, а настоящие сигналы от сломанного сервиса.

Система связала алерты в один инцидент и получила от модели готовый разбор: какая причина связывает симптомы, какой сервис пострадал первым и что делать дальше. Сергей не открыл ни одного дашборда и не зашёл по SSH ни на один хост. Все действия, которые обычно съедают первые полчаса инцидента, система выполнила сама, пока он комментировал происходящее в эфире.

Не группировка, а связь

Отдельно Сергей разграничил два похожих на первый взгляд понятия. Классическая группировка алертов происходит, когда одна и та же проблема (например, упавшая нода) спамит десятками однотипных сообщений и Alertmanager сворачивает их в одну группу.

Система, о которой рассказывал Сергей, делает другое: она устанавливает причинно-следственную связь между алертами из разных сервисов. На демо-стенде для этого используется временное окно (в презентации это минута: при более коротком окне не хватало времени для срабатывания связанных алертов, а при более длинном рос риск ложных связей) плюс совпадение лейблов и namespace. Если тревоги приходят из разных, логически не связанных пространств имён (например, из бизнес-сервиса и из системного Metal LB), система не станет их искусственно связывать.

Кстати, резолвы алертов система на модель принципиально не отправляет: в этом просто нет смысла, а токены не расходуются впустую.

Роль инженера: не автономность, а сокращение рутины

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

Мы не убираем инженера из цикла. Мы убираем из его работы 30 минут рутины, чтобы он раньше добрался до того, что умеет делать только инженер: принимать решение. Но если что-то пойдёт не так, отвечать тоже будет инженер. Это тоже база.

Метрика, которую закрывает решение, называется MTTA: это время до подтверждения инцидента, mean time to acknowledge. По оценке Сергея, оно сокращается с 20 до 30 минут ручного разбора до одной-двух минут, а зачастую и до секунд.

Ограничения, риски и вопросы безопасности

Аудитория задала Сергею немало предметных вопросов, в основном о надёжности и безопасности решения.

Может ли модель подставить инженера ложной гипотезой? Сергей подчеркнул, что модель ничего не делает сама: не заходит в прод, не удаляет ресурсы, а только собирает информацию и формирует гипотезу. Риск получить неточную рекомендацию есть, но он не выше, чем риск ошибиться, глядя на голый график: просто здесь у инженера сразу больше контекста для проверки. Источник неточности обычно один: неполный контекст, например, если событие произошло за пределами временного окна связывания.

Что с доступом к Kubernetes API? Только чтение через ограниченный RBAC: list, get, события, describe. Никаких прав на изменение ресурсов.

Что с персональными данными? В обогащённый алерт попадают только технические данные: имена нод, сервисов, метрики. Персональных данных там нет. Для более чувствительных сценариев Сергей допустил локальное развёртывание модели.

Как обстоят дела с «дешёвыми» локальными моделями? Здесь Сергей поделился неудачным личным опытом: при попытке развернуть модель Qwen локально ответы начинали «съезжать» на китайский язык, а обработка одного алерта занимала до двух минут, что для инцидента неприемлемо. На своём демо-стенде он использует Gemini Flash 2.5 через подписку OpenRouter. По его словам, за пару недель работы стенда с постоянными алертами это обошлось примерно в 20 центов.

Слишком длинный контекст тоже риск. Отдельно Сергей отметил: если «скормить» модели избыточно длинный JSON, она начинает генерировать длинный и менее точный ответ, вплоть до заметной деградации по времени и качеству. Здесь работает старое правило: если вопрос поставлен правильно, это уже половина ответа. Чем точнее и компактнее собран контекст, тем точнее рекомендация.

Что можно добавить: логи, телефония, другие источники метрик

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

• логи: в одном из прошлых внедрений к системе подключали Elasticsearch, это ещё сильнее обогащает алерт, но требует аккуратной работы с объёмом данных, которые передаются модели

• другие системы мониторинга: архитектура не завязана на Prometheus, подходит и Victoria Metrics, и Zabbix для мониторинга виртуальных машин и хостов вне Kubernetes-кластера

• телефония: прямой интеграции со звонками при критичных алертах пока нет, но Сергей допустил, что такое расширение реализуемо, если добавить в промпт дополнительные правила, определяющие, когда алерт достаточно критичен, чтобы будить дежурного звонком

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

Сергей отдельно подчеркнул, что для всех этих «продвинутых» фич нужны ресурсы (GPU, отдельная инфраструктура для хранения и обработки данных) и что для большинства компаний это не первоочередная инвестиция.

Ещё аудитория спрашивала

Заменит ли ИИ инженера? Сергей ответил на этот вопрос коротко и однозначно: нет, во всяком случае не в обозримой перспективе, и точно не сильного инженера. По его мнению, правильная рамка не «ИИ вместо инженера», а «инженер плюс ИИ как помощник, который снимает рутину». Он допустил, что модели уже сейчас можно доверить черновую работу, но окончательные решения и ответственность остаются у человека.

Сколько стоит внедрение такого решения? Точных цифр Сергей на публике не назвал, сославшись на коммерческую тайну прошлых пилотов. Он уточнил, что для небольших компаний с несложным мониторингом подобная автоматизация не критична, а вот для инфраструктуры с высокой ценой простоя (по его формулировке, «где минута простоя стоит миллион рублей») экономический эффект уже ощутим. Технически на подключение уходит немного: ссылки на Prometheus и Alertmanager, ключ Telegram-бота и ключ OpenRouter.

Нужно ли писать в промпте «думай как опытный инженер»? Сергей проверял это на практике и пришёл к выводу, что современным моделям такая приписка почти не нужна: раньше подобные формулировки заметно влияли на качество ответа, но по мере роста самих моделей эффект ослаб. Гораздо важнее оказались не общие установки про экспертизу, а конкретные правила и ключи вроде node.memory.pressure, которые явно говорят модели, что делать с конкретным сигналом.

Итоги доклада

Сергей закрыл доклад несколькими выводами, которые стоит зафиксировать отдельно.

Хорошо настроенный мониторинг прекрасно показывает, что горит, но не объясняет, почему это горит и что происходит вокруг события. Именно этот разрыв и есть самая дорогая часть инцидента: не сам фикс проблемы, а первые минуты неведения.

Собирать контекст вручную, по десяткам дашбордов, через describe, по логам, можно автоматизировать самыми обычными инженерными средствами: сбор данных, обогащение по заранее подготовленным сигналам, чёткий промпт с жёсткими рамками формата и объёма.

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

Исходный код проекта, который Сергей показывал на демо, открыт на GitHub: github.com/sersert/IncidentGPT. Автор сам зовёт сообщество форкать репозиторий и присылать pull request’ы, так что если есть идея, как сделать агента ещё полезнее, велком.

Это конспект только первого из шести занятий «Вечерней школы. ИИ для инженеров: польза и риски», а дежурства, к сожалению, случаются не только у DevOps-инженеров. Дальше в программе были автофикс проблем прода, ИИ-агенты для бизнес-задач, юридические риски использования ИИ, дообучение LLM под конкретный SOC и разговор о том, как вообще меняется инженерное мышление в эпоху LLM. Если тема зашла, лучше досмотреть школу целиком, чем потом судорожно гуглить, что такое MTTA, в три часа ночи.

Посмотреть запись этого занятия можно на YouTube по прямой ссылке, а все шесть занятий школы собраны в плейлисте «Вечерней школы. ИИ для инженеров». Устраивайся поудобнее, чай можно уже не экономить.

А если хочется пройти всю школу целиком, с материалами и файлами для практики после каждого занятия, доступ к курсу на обучающей платформе Слёрма открывается через Telegram-бота: t.me/ai_slurm_bot.