Проблема: ночные звонки и тысячи логов
В три часа ночи просыпается не дежурный инженер, а его телефон. В кластере Kubernetes падает критичный микросервис. Пока он пытается открыть глаза, система мониторинга уже засыпала Slack сотней алертов. Логи из десятка подов, метрики, события - все кричит одновременно. Первые 20 минут уходят не на решение, а на поиск иголки в стоге сена. Знакомо?
В IVI, где сотни сервисов работают на десятках кластеров, эта проблема перестала быть эпизодической. Дежурные тонули в данных. Традиционные правила в мониторинге (типа "если CPU > 90%") давали больше ложных срабатываний, чем полезных сигналов. Нужен был не просто еще один алерт, а интеллектуальный фильтр, способный связать разрозненные сигналы в причинно-следственную цепочку.
Самая большая ошибка в таком сценарии - пытаться заставить AI-агента действовать автономно, как в той самой статье про сломанных агентов. Мы сразу отказались от идеи давать агенту права на исправление проблем. Его задача - только диагностика. Потому что в 2026 году даже самые продвинутые модели, вроде Gemini 3.0 Ultra, все еще не понимают контекст кластера на уровне человека.
Решение IVI: AI-агент как первый ответчик
Вместо того чтобы создавать очередную систему правил, команда инфраструктуры IVI построила AI-агента, который работает как умный помощник дежурного. Его цель - сократить среднее время на диагностику (MTTD) с 40 минут до 5. Агент не принимает решений. Он задает вопросы кластеру, анализирует ответы и выдает гипотезу: "С высокой вероятностью проблема в исчерпании лимитов памяти у пода frontend-api, что привело к OOMKill и перезапускам, которые увеличили нагрузку на балансировщик".
Ключевое отличие от простых анализаторов логов - агент умеет вести диалог с инфраструктурой. Он не просто парсит ошибки, а строит цепочку событий, используя знания о типичных проблемах Kubernetes.
Архитектура: от логов до диагноза
Агент работает как микросервис внутри того же кластера, который он мониторит. Это важно - так он имеет минимальную сетевую задержку к API Kubernetes и логам. Архитектура выглядит деceptively простой, но каждый компонент решает конкретную проблему.
| Компонент | Задача | Технология (на 28.01.2026) |
|---|---|---|
| Сборщик контекста | Агрегирует логи, метрики, события K8s за последние 15 минут | Vector + OpenTelemetry |
| Оркестратор промптов | Управляет цепочкой запросов к LLM, решает, какие данные запросить дальше | LangChain 0.3.0 (поддержка Gemini 3.0) |
| LLM-движок | Анализирует данные, строит гипотезы | Gemini 3.0 Flash (для скорости) + Gemini 3.0 Pro (для сложных случаев) |
| Валидатор | Проверяет выводы модели на наличие опасных рекомендаций | Набор регулярных выражений + эвристики |
| Интегратор | Отправляет отчет в Slack, создает тикет в Jira | Python-сервис с webhook |
Почему именно такая схема? Потому что скармливать все логи разом в LLM - дорого и бесполезно. Модель теряется в объеме. Вместо этого агент действует как опытный врач: сначала собирает анамнез (общие метрики), затем назначает анализы (запрашивает конкретные логи), ставит предварительный диагноз.
Промпты, которые работают: примеры и логика
Самый важный секрет - не в модели, а в промптах. Глупый промпт получит глупый ответ. Наша библиотека промптов выросла до 50+ шаблонов, каждый для своего типа проблемы.
Базовый промпт для анализа событий Kubernetes:
role: "Ты - старший инженер DevOps с 10-летним опытом работы с Kubernetes.
Ты анализируешь события из кластера для поиска причин проблем.
Твоя задача - найти цепочку событий, которая привела к инциденту.
Правила:
1. Не предлагай никаких действий по исправлению.
2. Говори только о том, что видишь в данных.
3. Если данных недостаточно, скажи, что именно нужно запросить.
Формат ответа:
- Основная гипотеза (одно предложение)
- Критичность (высокая/средняя/низкая)
- Цепочка событий (по времени)
- Недостающие данные для подтверждения"
data: "{events_data}"
question: "Какая последовательность событий привела к текущему состоянию?"Промпт для анализа логов приложения с подозрением на утечку памяти:
role: "Ты - эксперт по профилированию Java-приложений.
Ты видишь логи приложения за последние 10 минут.
Ищи паттерны, указывающие на проблемы с памятью: частые сборки мусора, OutOfMemoryError, рост heap.
Особое внимание удели:
1. Частоте вызовов System.gc()
2. Изменению времени сборки мусора
3. Сообщениям об исчерпании метаспейса
Если видишь явные признаки утечки, укажи, в каком компоненте она может быть (например, кэш, connection pool).
Если признаков нет, скажи об этом.
Не придумывай то, чего нет в логах."
data: "{logs_snippet}"
question: "Есть ли в этих логах признаки утечки памяти? Если да, то какие?"Почему эти промпты работают? Они ограничивают модель конкретной ролью и задачей. Они запрещают модели предлагать действия (это опасно). Они требуют структурированного ответа. И они честно говорят модели, когда данных недостаточно.
Самая частая ошибка - делать промпт слишком общим. "Проанализируй логи" - это билет в ад. Модель начнет фантазировать. Нужно зажать ее в жесткие рамки, как новичка на стажировке. Да, это требует больше работы по проектированию промптов, но это единственный путь к стабильности. Больше об этом подходе в статье про суб-агентов.
Интеграция с Slack: как агент говорит с командой
Агент не живет в вакууме. Его выводы должны моментально попадать к людям. Мы подключили его к Slack через Bolt API. Но не как простого бота, который спамит сообщениями.
Каждое сообщение агента имеет четкую структуру:
- Эмодзи критичности: 🔴 для высокой, 🟡 для средней, 🔵 для низкой
- Одна строка - суть проблемы: "Падение пода payment-service из-за превышения лимитов памяти"
- Кнопки действий: "Показать логи", "Показать метрики", "Создать тикет"
- Тэги: Указываются сервис, тип проблемы, кластер
Когда дежурный нажимает "Показать логи", агент не вываливает тысячу строк. Он использует второй промпт для извлечения только релевантных строк и форматирует их с подсветкой синтаксиса.
Интеграция с Jira автоматическая только для проблем высокой критичности. Агент сам заполняет описание, используя шаблон, и прикрепляет ключевые логи. Для средних и низких проблем он только предлагает создать тикет - окончательное решение за человеком.
Пошаговый план: как собрать своего агента
1Соберите стек данных
Без качественных данных агент слеп. Настройте сбор логов (Fluent Bit или Vector), метрик (Prometheus) и событий Kubernetes (Event Router) в единое хранилище. Мы используем Yandex Managed Kubernetes с его встроенной интеграцией мониторинга, что экономит время. Важно: данные должны быть доступны с низкой задержкой. Агент будет запрашивать их в реальном времени.
2Выберите модель и фреймворк
На 28.01.2026 Gemini 3.0 Flash - оптимальный выбор для задач анализа текста (логов) по соотношению скорость/цена/качество. Для фреймворка оркестрации мы выбрали LangChain 0.3.0, но с минимальным использованием его абстракций. Большинство промптов пишется вручную, цепочки простые. Не переусложняйте. Создайте простой Python-сервис, который будет получать webhook от системы мониторинга (например, от Datadog или Alertmanager).
3Напишите ядро промптов
Начните с трех самых частых проблем в вашем кластере. Например: 1) Падение пода, 2) Высокая загрузка CPU, 3) Ошибки сети. Для каждой создайте промпт-шаблон. Протестируйте их на исторических данных. Измеряйте не только "понравился ли ответ", а "привел ли этот ответ к правильному решению".
4Добавьте валидацию и безопасность
Любой вывод модели должен проходить через валидатор. Простейший вариант - список запрещенных фраз ("удалить", "остановить", "перезагрузить"). Более сложный - проверка рекомендаций на соответствие best practices вашей компании. Никогда не давайте агенту права на запись в кластер. Только чтение.
5Интегрируйте с workflow команды
Агент должен встраиваться в существующие процессы. Если команда использует Slack - делайте интеграцию туда. Если тикеты в Jira - настройте автоматическое создание. Ключ - не создавать новый канал коммуникации, а использовать уже привычный. Обязательно добавьте кнопку "Это ложное срабатывание" для обратной связи.
Нюансы, которые бесят: что не написано в документации
Реализация выглядит прямой, но подводных камней хватает.
- Токены дорожают. Анализ 100К логов через GPT-4 может стоить 10$. Поэтому мы агрессивно фильтруем данные до отправки в модель. И используем более дешевые модели для первичного фильтра.
- Модель галлюцинирует на пустом месте. Если в логах есть странная, но не критичная ошибка, модель может раздуть ее до апокалипсиса. Решение - давать модели контекст о "нормальности" (например, "эта ошибка встречается в 5% запросов и является ожидаемой").
- Задержки убивают полезность. Если агент думает 2 минуты, дежурный уже сам все нашел. Оптимизируйте цепочки промптов. Кешируйте ответы на частые вопросы. Используйте потоковую передачу ответов в интерфейс.
- Смена версий API ломает все. Google, OpenAI и другие регулярно меняют API. Ваш код должен быть готов к этому. Изолируйте работу с моделью в отдельный сервис с четким контрактом.
Самое сложное - не техническая часть, а изменение процессов. Дежурные сначала не доверяли агенту. Потом начали слепо доверять. Пришлось проводить обучение: агент - это помощник, а не истина в последней инстанции. Его гипотезы нужно проверять.
Итоги: на что способен агент через 6 месяцев
В IVI агент работает в production с августа 2025 года. Цифры:
- Среднее время на диагностику (MTTD) упало с 40 до 8 минут.
- Количество ночных вызовов дежурным снизилось на 60%.
- Агент обрабатывает 85% всех алертов автоматически, и только 15% требуют вмешательства человека.
- Ложные срабатывания системы мониторинга сократились, потому что агент научился отличать временные всплески от реальных проблем.
Но главный результат не в метриках. Дежурные перестали быть пожарными. Они стали инженерами, которые решают сложные проблемы, а не ищут, где горит. Агент взял на себя рутинную работу по первичному анализу.
Следующий шаг - научить агента не только диагностировать, но и предлагать конкретные команды для исправления (с подтверждением человека). И тут нам пригодится дисциплина Agent Engineering, чтобы не наступить на те же грабли, что и с автономными агентами.
Стоило ли оно того? Если ваш кластер горит чаще двух раз в месяц - однозначно да. Если все стабильно - может, и подождать. Но помните: AI-агенты для инфраструктуры - это не будущее. Это настоящее, которое просто еще не везде наступило.
