AI-агенты в DevOps: кто чинит инцидент раньше дежурного

За последний год мониторинг перестал ограничиваться графиками и алертами. PagerDuty, Datadog, Grafana и облачные провайдеры добавили в свои продукты LLM-агентов^*, которые обещают не только заметить сбой, но и найти его причину, а иногда и выполнить восстановление без человека. Формулировки в маркетинге громкие — «автономный SRE», «self-healing». За ними скрываются очень разные вещи: от чат-бота, который пересказывает логи, до системы, которая реально имеет право перезапустить под в кластере.

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

Что вообще делает AI-агент в цепочке инцидента

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

• Триаж. Агент собирает контекст вокруг алерта — связанные метрики, недавние деплои, изменения конфигов — и формулирует гипотезу о причине человеческим языком.
• Диагностика. Агент сам выполняет запросы к логам, трейсам и системам, задаёт уточняющие подзапросы и сужает круг подозреваемых сервисов.
• Восстановление. Агент выполняет действие: откат деплоя, перезапуск, масштабирование, изоляция ноды. Это самая спорная часть — здесь ошибка агента становится вторым инцидентом.

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

Почему это стало возможно только сейчас

Дело не в том, что LLM внезапно поумнели, а в том, что вокруг них выросла обвязка. Модель получила доступ к инструментам через вызов функций, а контекстное окно^** выросло настолько, что в один запрос помещаются логи, конфиги и история изменений. Плюс подход RAG^*** позволяет подтягивать в контекст внутренние runbook и прошлые постмортемы, а не полагаться на общие знания модели о Kubernetes.

Кто что предлагает

Ниже — сопоставление подходов у нескольких заметных игроков. Возможности и доступность меняются от релиза к релизу, поэтому конкретные лимиты и цены сверяйте на официальных страницах продуктов; в таблице — тип функциональности, а не гарантированный SLA.

Общий вектор одинаков: диагностику отдают агенту охотно, право нажать кнопку — крайне неохотно. И это разумно.

Агент, который сам откатывает деплой, экономит минуты дежурному ценой риска, что он откатит не тот сервис в три часа ночи. Пока индустрия предпочитает медленного человека быстрому агенту с правами root.

Где проходит граница доверия

Главная развилка при внедрении — какие действия агенту разрешено выполнять самому. Практика сводится к трём уровням автономии.

1. Только чтение. Агент читает метрики, логи, конфиги и пишет гипотезу. Ничего не меняет. Самый безопасный и самый распространённый режим.
2. Действие с подтверждением. Агент готовит конкретную команду (например, откат до предыдущего образа) и ждёт нажатия человека. Экономит время на составлении команды, но оставляет решение за инженером.
3. Автономное восстановление в песочнице правил. Агент выполняет действия сам, но только из белого списка операций и с жёсткими лимитами: не трогать stateful-сервисы, не масштабировать выше N реплик, при неуверенности — эскалировать человеку.

Третий уровень оправдан для узких, часто повторяющихся и обратимых инцидентов: перезапуск зависшего пода, очистка переполненного диска по known-паттерну, добавление реплик под предсказуемый всплеск. Для необратимых операций — миграций БД, изменения сетевых политик, работы с платёжным контуром — автономию не отдают, и правильно делают.

Кому это пригодится, а кому нет

Пригодится

• Командам с большим потоком однотипных алертов. Если дежурного будят десятки раз за ночь, и половина — шум, агент-группировщик и первичный триаж снимают реальную усталость и ускоряют реакцию на настоящие инциденты.
• Сервисам с хорошо документированными runbook. Чем лучше у вас описаны прошлые инциденты и процедуры, тем полезнее RAG-агент: он подтянет нужный runbook быстрее, чем человек вспомнит, где тот лежит.
• Небольшим командам без круглосуточного дежурства. Агент на уровне «чтение + подсказка» частично закрывает нехватку рук ночью, давая заготовленный анализ к моменту, когда человек всё же проснётся.

Не пригодится (или навредит)

• При плохой наблюдаемости. Если метрики и логи неполные или зашумлённые, агент будет уверенно галлюцинировать причину сбоя. Мусор на входе — правдоподобная чушь на выходе.
• В критичном контуре без ограничителей. Давать автономные права на платёжную инфраструктуру или базы данных — приглашение к инциденту, который агент сам же и устроит.
• Как замена SRE-культуре. Агент не построит вам процессы, SLO и постмортемы без вины. Он ускоряет то, что уже налажено, и усиливает бардак там, где его нет.

Что учесть перед пилотом

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

• Аудит действий. Каждое действие агента должно логироваться так же строго, как действия человека, — с возможностью разобрать постфактум, кто и что сделал.
• Данные в модели. Уточните, куда уходят ваши логи и конфиги при обращении к LLM и не утекают ли туда секреты. Для чувствительных контуров это блокирующий вопрос.
• Стоимость на инцидент. Длинные контексты с логами — это токены, а токены — деньги. При потоке алертов счёт за инференс может оказаться заметным, оценивайте его на реальных данных, а не на демо.
• Поведение при неуверенности. Хороший агент честно эскалирует, когда не понимает причину. Плохой — придумывает объяснение. Это стоит проверять на боевых инцидентах в режиме чтения, прежде чем давать права.

^* Агент — здесь: программа на основе языковой модели, которая не просто отвечает текстом, а вызывает внешние инструменты (запросы к логам, команды в кластер) и действует по шагам для достижения цели.

^** Контекстное окно — объём текста (в токенах), который модель способна учитывать за один запрос; чем оно больше, тем больше логов и конфигов влезает в один анализ.

^*** RAG (retrieval-augmented generation) — подход, при котором модель перед ответом подтягивает релевантные внешние документы (например, ваши runbook) и опирается на них, а не только на знания из обучения.