AI SRE

Что делает AI SRE

AI SRE — ассистент инженера, который помогает исследовать состояние production: собирает связанные события, сопоставляет изменения с телеметрией и формулирует проверяемые гипотезы. Это не автономный владелец сервиса и не замена процессу реагирования.

Полезная особенность подхода — работа сразу с несколькими источниками:

• недавние деплои и изменения конфигурации;
• логи, метрики, трассировки и исключения;
• карта сервисов и зависимостей;
• внешние проверки и пользовательские события;
• хронология инцидента, runbooks и прошлые postmortem.

Например, ассистент может обнаружить, что рост p95 начался после релиза, локализовать медленный span и предложить проверить изменённый запрос к базе. Вывод остаётся гипотезой, пока инженер не подтвердил её данными.

Рабочий сценарий

Сигнал → сбор контекста → 2–3 гипотезы → доказательства за/против
      → проверка человеком → одобренное действие → наблюдение за результатом

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

MCP и другие интерфейсы

Через Model Context Protocol (MCP) телеметрию и операции можно подключить к существующему LLM-интерфейсу. Другой вариант — встроенный чат в Slack, Teams или продукте наблюдаемости.

Технический интерфейс не гарантирует безопасность. Для подключения нужны:

• отдельные учётные данные с минимально необходимыми правами;
• read-only доступ по умолчанию;
• список разрешённых источников и операций;
• маскирование секретов и персональных данных;
• журнал запросов и вызванных инструментов;
• сроки хранения и регион обработки, согласованные с требованиями проекта.

Данные из логов и внешних систем могут содержать вредоносные инструкции. Ассистент должен рассматривать их как данные расследования, а не как команды.

Границы автономности

• Допустимо автоматически: искать события, строить сводки, сравнивать периоды, предлагать гипотезы и черновики postmortem.
• Только после явного подтверждения: создавать тикет, менять статус инцидента, отправлять внешнее сообщение или формировать pull request.
• Не отдавать без отдельной защищённой системы контроля: rollback, изменение production-конфигурации, масштабирование, перезапуск и любые деструктивные операции.

Human-in-the-loop должен видеть, какое действие и на каком окружении будет выполнено. Одного общего разрешения «действуй» недостаточно.

Ограничения подхода

AI не восполняет отсутствие instrumentation: без correlation IDs, свежих метрик и истории деплоев ассистент получает неполный контекст. Он может неверно связать совпавшие по времени события или выдать уверенный ответ без доказательств. Поэтому полезно требовать ссылки на конкретные логи, spans, графики и изменения.

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

Связанные инструменты

• Better Stack — AI SRE, телеметрия, MCP и управление инцидентами.
• OpenTelemetry — переносимый сбор трасс, метрик и логов.
• Sentry — исключения, releases и контекст ошибок.

Связанные материалы

• SRE — инженерная практика, внутри которой работает ассистент.
• Управление инцидентами — роли и процесс восстановления.
• Наблюдаемость AI-агентов — оценка поведения и стоимости самих агентных систем.

Материалы и источники

• Better Stack: AI SRE — пример корреляции телеметрии, MCP и human-in-the-loop.
• Google SRE: Managing Incidents — роли и координация при восстановлении.
• OpenTelemetry: Observability primer — источники данных для анализа системы.
• Model Context Protocol: Security — практики безопасности MCP-подключений.