AI SRE-агенты в 2026: что они реально делают и где ломаются

В марте 2026 и AWS DevOps Agent, и Microsoft Azure SRE Agent ушли в общую доступность. Заголовки тут же написали «AI заменит on-call» — и почти все промахнулись мимо сути. Рабочая модель, которая реально прижилась в продакшене, совсем другая: агент берёт на себя триаж, корреляцию сигналов и выполнение runbook-ов, а решения и доступы остаются за человеком. Разберёмся, что это значит на практике и где проходит граница.

Содержание

Почему это стало практикой именно сейчас

До GA-релизов AWS и Microsoft тема AI в инцидент-менеджменте была полем демо и пилотов: независимые игроки вроде Rootly, Augment и NewRelic SRE Agent показывали корреляцию алертов на конференциях, но крупные облака держались в стороне. Как только оба гиперскейлера синхронно вывели собственных агентов в GA, разговор сменился с «а это вообще работает?» на «как это внедрить, не потеряв контроль над продом». Независимые агенты за это время тоже созрели — научились не просто предлагать текст, а дергать реальные API observability-стека и открывать pull request-ы с фиксом конфига.

Разница с 2023–2024 годами в одном: раньше «AI в SRE» означало чат-бота поверх логов, который отвечает на вопросы. Сейчас это агент с доступом к инструментам, который может действовать — открыть тикет, откатить деплой, перезапустить под. Именно этот шаг от «отвечает» к «действует» и требует новой модели границ доступа, а не косметических изменений в промпте.

Иллюзия «AI заменит on-call»

Маркетинг обеих платформ временами звучит так, будто агент берёт дежурство целиком. На практике происходит другое: как только агент получает право действовать без подтверждения, у команды пропадает единственный работающий контроль качества инцидент-менеджмента — человек, который видит контекст и может сказать «нет, не в этот раз». Модель «AI заменяет on-call» ломается ровно там, где ломается любая полностью автономная система в проде: на границе между «система уверена» и «система права».

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

Что агент реально умеет

Список того, что уже работает надёжно в проде у команд, которые внедрили AWS DevOps Agent, Azure SRE Agent или независимые аналоги:

• Парсинг и дедупликация алертов — сотни срабатываний Prometheus/Datadog схлопываются в один инцидент с понятной таймлайном.
• Корреляция с деплоями — агент сопоставляет время начала деградации с последними изменениями в CI/CD, репозитории конфигов, feature-flag системе.
• Predicted rollback target — не просто «откатить», а конкретная версия/коммит, к которой стоит откатиться, с обоснованием по метрикам.
• Сбор контекста в одном месте — логи, трейсы, недавние алерты и связанные тикеты собираются в единую сводку до того, как человек открыл терминал.
• Черновик runbook-шагов — агент предлагает последовательность команд из уже существующего runbook, адаптированную под конкретный инцидент.

Общее у всех пунктов: агент ускоряет путь к решению, но само решение — предложение, которое ещё нужно одобрить.

Что агент не умеет — и почему это не баг, а граница

Три категории систематических отказов встречаются у всех платформ одинаково.

Непрозрачные системы. Если у сервиса нет структурированных логов, трейсинга и метрик с осмысленными лейблами, агенту не с чем коррелировать. Он либо молчит, либо — хуже — выдаёт уверенную, но неверную гипотезу, потому что модель обучена всегда что-то отвечать. Observability — это предпосылка для AI SRE, а не опция.

Отсутствие ground truth по нормальному поведению. Агент хорошо ловит отклонение от паттерна, который видел раньше. На сервисах с редким, взрывным или сезонным трафиком (распродажи, релизные окна) базовая линия «нормы» смазана, и агент либо поднимает лишний шум, либо пропускает реальную деградацию.

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

Human-in-the-loop: как выглядит граница на практике

Три механики держат агента в безопасном коридоре, и все три обязательны — по отдельности они не работают.

• Scoping — агенту явно перечисляют, какие действия разрешены (обычно — список runbook ID или конкретных API-вызовов), а не выдают широкую роль «оператор». Всё, чего нет в списке, агент не может выполнить технически, а не «не должен по политике».
• Audit trail — каждое предложение, каждое одобрение и каждое выполненное действие агента логируется отдельно от обычных логов приложения, с привязкой к личности того, кто одобрил. Это не опция для комплаенса — это единственный способ разобрать постфактум, где агент ошибся.
• Approval gates — точка, где человек явно подтверждает действие до его выполнения. Критично: gate должен показывать обоснование, а не только команду — иначе approve превращается в ритуальный клик, и человек фактически перестаёт быть контролем.

Сравнение: что агент делал бы «по умолчанию» против того, что ему стоит разрешать

Что нужно, чтобы включить безопасного AI SRE-агента

Минимальный безопасный setup — это две группы прав и один сценарий. Права: read-only доступ к observability-стеку (метрики, логи, трейсы, топология сервисов) — здесь агенту можно давать доступ широко, потому что чтение не создаёт риска отказа. И write-доступ, но только к заранее одобренному набору runbook-команд — не к произвольному shell, не к API кластера напрямую.

Пример минимальной scoping-политики для агента (независимо от того, AWS это, Azure или самописный оркестратор поверх LLM):

agent_scope:
  read:
    - observability.metrics
    - observability.logs
    - observability.traces
    - deploy_history
  write:
    allowed_runbooks:
      - restart-pod-crashloop
      - scale-replica-count
      - rollback-to-previous-tag
    require_approval: true
    approval_timeout_minutes: 15
  forbidden:
    - prod_credentials
    - kill_switch
    - iam_policy_changes
    - database_direct_access

Сценарий инцидента с таким setup выглядит так: срабатывает алерт → агент собирает контекст (метрики, недавние деплои, похожие прошлые инциденты) → агент предлагает конкретное действие из allowed_runbooks с обоснованием → человек видит предложение и обоснование в approval gate → одобряет или отклоняет → при одобрении агент выполняет и пишет результат в audit trail. Если предложенное действие не входит в allowed_runbooks, агент физически не может его выполнить — он может только эскалировать человеку с текстовым предложением, без кнопки execute.

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

Одной документации scoping-политики недостаточно — нужен негативный тест. Дайте агенту команду, которая заведомо не входит в allowed_runbooks (например, попросите его напрямую изменить IAM-политику или обратиться к prod-креду), и убедитесь, что он не может это выполнить технически, а не просто «отказывается по инструкции в промпте». Разница огромная: инструкция в промпте обходится другим промптом, техническое ограничение доступа — нет.

# пример: запрос к agent API с заведомо запрещённым действием
curl -s -X POST https://agent.internal/actions \
  -H "Authorization: Bearer $AGENT_TOKEN" \
  -d '{"action":"database_direct_access","target":"prod-primary"}'
# ожидаемый ответ: 403, действие не входит в agent_scope.write

Второй тест — прогоните смоук-инцидент end-to-end и сверьте audit trail: каждое действие агента должно быть в логе с привязкой к личности того, кто одобрил, и с исходным обоснованием, а не только с фактом «выполнено».

Частые грабли

• Approval gate без обоснования. Если в интерфейсе одобрения видна только команда, а не «почему агент так решил», approve быстро превращается в рефлекс, и человек перестаёт быть реальным контролем.
• Widening scope «временно», чтобы разобраться с инцидентом быстрее. Временные расширения прав почти никогда не откатываются вовремя — это тот же паттерн, что и с постоянными root-доступами у людей.
• Один audit trail на всё. Логи действий агента, смешанные с обычными логами приложения, невозможно быстро отфильтровать при разборе инцидента, вызванного самим агентом.
• Доверие агенту в непрозрачных системах. Если у сервиса нет нормальной observability, добавление AI-агента не чинит эту проблему — оно добавляет к «мы не видим, что происходит» ещё и «агент действует, не видя, что происходит».
• Отсутствие негативного теста на права. Политика scoping, которую ни разу не пытались обойти нарочно, часто оказывается шире, чем кажется на бумаге.

Итог

AI SRE в 2026-м — это не «замена on-call», а второй пилот с очень узким коридором действий. Технологически агенты AWS, Azure и независимых игроков уже умеют полезную часть работы: разгребать шум алертов, находить корреляции быстрее человека и предлагать конкретный план вместо общих слов. Но вся польза этой модели держится на одном решении, которое команда принимает заранее — где именно проходит граница read-only, write-по-одобрению и категорически запрещённого. Правильно ограниченный агент экономит часы на триаже. Агент с широким доступом «чтобы не мешал одобрениями» — это не second pair of hands, а новый источник инцидентов, который к тому же сложнее разбирать постфактум, потому что решение принимала не человек.