Guardrails для AI SRE-агентов: как разрешать автоматизацию, не теряя контроль

AWS DevOps Agent и Azure SRE Agent — оба в GA с марта 2026 года — умеют находить root cause инцидента быстрее любого дежурного инженера. Но ни один из вендоров не разрешает им напрямую откатывать деплой, рестартовать под или скейлить продакшн: между диагнозом агента и реальным изменением почти везде стоит человек, нажимающий кнопку. Разбираемся, как спроектировать этот approval gate самостоятельно — поверх уже работающего incident-пайплайна, а не в ожидании, что вендор соберёт его за вас.

Содержание

Что уже умеют AI SRE-агенты

AWS DevOps Agent вышел в GA 31 марта 2026-го, Azure SRE Agent — 10 марта 2026-го (InfoQ). У обоих одна и та же рабочая модель: агент подписывается на алерты, коррелирует их с последними деплоями, читает логи и трейсы, формулирует вероятный root cause и предлагает конкретное действие — но production-изменения категории «рестарт, откат, скейлинг» всё ещё идут через явное подтверждение человека. PagerDuty параллельно готовит MCP-фабрику, чтобы несколько таких агентов от разных вендоров подключались к одному инцидент-пайплайну через общий протокол, а не через десяток частных интеграций.

Мы уже разбирали в целом, что такое AI SRE-агент и где он ломается — какие данные ему нужны, какие права давать нельзя в принципе. Этот текст — не повтор того разбора, а следующий шаг: как именно встроить approval gate в уже существующий on-call процесс, если агент (свой или вендорский) у вас уже есть или появится в ближайшее время.

Три уровня автономности

Прежде чем проектировать гейт, полезно разложить «автономность» на уровни — потому что именно между вторым и третьим находится вся суть guardrail-архитектуры.

• Read-only triage. Агент читает метрики, логи, трейсы и историю деплоев, строит таймлайн и формулирует гипотезу о причине. Никакого доступа на запись ему для этого не нужно вообще — только read-scoped токены к observability-стеку.
• Предложенный фикс. Агент называет конкретное действие: «откатить checkout на ревизию a1b2c3», «увеличить replicas до 6», «рестартовать под payments-7f9c» — вместе с обоснованием и оценкой blast radius. Команда формулируется, но не выполняется.
• Auto-remediation. Агент сам выполняет предложенное действие, без паузы на подтверждение — обычно в узких, заранее одобренных рамках (конкретный namespace, конкретный набор команд).

Большая часть заявленной пользы AI SRE 2026 года реализуется уже на первых двух уровнях: диагностика, которая раньше занимала 20–30 минут ручной корреляции логов и графиков, сжимается до секунд. Третий уровень добавляет скорость реакции, но именно он требует настоящей guardrail-инженерии — и именно на границе между «предложил» и «выполнил» нужен approval gate.

Approval gate поверх существующего on-call инструмента

Ключевое архитектурное решение — не встраивать одобрение в код самого агента, а вынести его в тот инструмент, где дежурный и так работает: Slack, PagerDuty, Opsgenie. Тогда approval gate бесплатно наследует то, что в этих системах уже настроено — RBAC, on-call расписание, историю сообщений как готовый аудит-лог.

Из этого вытекают конкретные архитектурные требования:

• Агент не имеет учётных данных к продакшену. Он публикует структурированное предложение (какая команда, над каким объектом, зачем, какой blast radius) через webhook в канал инцидента — и всё. Выполнение — задача отдельного компонента.
• Одобрение — явное действие, а не свободный текст. Реакция ✅ на конкретное сообщение или отдельная кнопка в интерактивном блоке Slack однозначно идентифицируют, кто и что именно одобрил. Фраза в духе «ну давай, откатывай» в общем чате юридически и технически бесполезна как запись аудита.
• Executor — отдельный сервис с собственной узкой ролью. Он подписан на события одобрения (Slack Events API, PagerDuty webhook) и выполняет только тот набор команд, под который у него есть права — независимо от того, что «попросил» агент.
• У предложения есть срок жизни. Если дежурный не отреагировал за 5–10 минут, предложение считается устаревшим и требует повторной генерации — состояние кластера могло уже измениться, и одобрение по старым данным опаснее, чем его отсутствие.

Что логировать для аудита

Approval gate без аудита — просто более медленная версия auto-remediation с лишним кликом. Ценность всей конструкции — в том, что после инцидента можно точно восстановить цепочку решений:

• кто одобрил — identity из Slack/PagerDuty, а не «агент решил», потому что решение формально принимал человек;
• точный текст диагноза агента на момент одобрения, зафиксированный неизменяемо — если позже окажется, что причина была другой, у вас есть снимок того, на основании чего было принято решение;
• какая команда и над каким объектом реально выполнена executor’ом — это может не совпадать с тем, что предложил агент, если дежурный подправил параметры перед одобрением;
• исход — стало ли лучше, пришлось ли откатывать откат. Этот сигнал стоит собирать отдельно и системно: он единственный способ увидеть, что диагноз агента конкретного типа инцидентов регулярно ошибается, и скорректировать доверие к нему, а не к модели в целом.

Граница: что никогда не должно идти без approval

Даже если agent показывает стабильно высокую точность диагнозов, есть категории действий, которые не стоит переводить на auto-remediation вообще, независимо от истории одобрений:

• операции с данными — удаление, миграции схемы, что угодно необратимое;
• всё, что касается денег — биллинг, лимиты трат, платёжные интеграции;
• изменения внешнего трафика за пределами уже одобренных границ — DNS, вес бэкендов на балансировщике, публичные ingress-правила;
• секреты и IAM — выдача или отзыв прав, ротация ключей.

Эти категории объединяет одно: цена ошибочного автоматического действия здесь не «пришлось откатить деплой», а «данные потеряны» или «доступ скомпрометирован» — асимметрия, которую никакой процент точности агента не компенсирует.

Сравнение: без гейта и с гейтом

Что нужно, чтобы собрать минимальный approval gate

Понадобится: канал инцидентов в Slack, incoming webhook для публикации предложений от агента, и отдельный сервисный аккаунт в кластере — не тот, под которым работает сам агент.

Сначала — узкая RBAC-роль для executor’а, которая может делать ровно то, что нужно для отката деплоя, и ничего больше:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: sre-agent-executor
  namespace: prod
rules:
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets"]
    verbs: ["get", "list", "watch", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: sre-agent-executor-binding
  namespace: prod
subjects:
  - kind: ServiceAccount
    name: sre-agent-executor
    namespace: prod
roleRef:
  kind: Role
  name: sre-agent-executor
  apiGroup: rbac.authorization.k8s.io

Дальше — исполнитель, который слушает реакции в Slack и запускает kubectl rollout undo только после подтверждения от известного одобряющего:

# упрощённый обработчик Slack Events API
on_reaction_added() {
  local reaction="$1" user="$2" message_ts="$3"

  [[ "$reaction" == "white_check_mark" ]] || return 0
  is_authorized_approver "$user" || return 0

  local proposal
  proposal=$(fetch_proposal_by_ts "$message_ts")   # структурированное предложение агента
  is_proposal_expired "$proposal" && return 0

  log_audit_entry --approver "$user" --diagnosis "$proposal" --ts "$message_ts"

  kubectl --as=system:serviceaccount:prod:sre-agent-executor \
    -n prod rollout undo deployment "$(jq -r .target <<<"$proposal")"
}

Агенту при этом достаточно read-only доступа к observability-стеку и права постить в Slack-канал — kubeconfig от продакшена он не видит вообще.

Как проверить, что всё работает

Убедитесь, что узкая роль действительно узкая — executor может то, что должен, и не может ничего сверх этого:

kubectl auth can-i patch deployments \
  --as=system:serviceaccount:prod:sre-agent-executor -n prod
# yes

kubectl auth can-i delete secrets \
  --as=system:serviceaccount:prod:sre-agent-executor -n prod
# no

Затем прогоните тестовое предложение целиком: агент (или его заглушка) публикует сообщение в Slack, вы реагируете ✅, и в логе executor’а должна появиться запись с вашим именем, точным текстом диагноза и результатом kubectl rollout undo. Если запись появилась без вашей явной реакции — гейт не работает, и это нужно найти до того, как агент начнёт предлагать реальные фиксы на проде.

Итог

Ценность AI SRE-агента 2026 года — не в том, что он умеет действовать сам, а в том, насколько быстрее он ставит диагноз по сравнению с ручной корреляцией логов и графиков. Auto-remediation можно и стоит расширять постепенно, но безопасно это делать только через explicit approval-gate — отдельный executor с узкой ролью, явное подтверждение конкретного человека и полный аудит-след от диагноза до результата, — а не через растущее доверие к точности модели. Доверие к модели меняется от инцидента к инциденту; узкая RBAC-роль и обязательный клик дежурного — нет.