AI SRE Agent не заменит on-call

PagerDuty 12 марта 2026 выкатили Spring 2026 release с важным сигналом: SRE Agent как virtual responder, которого можно будет добавлять в schedules и escalation policies. Он первым смотрит на инцидент, делает triage/diagnosis и только потом будит человека.

Звучит как мечта: в 03:17 просыпается не инженер, а коробка с LLM внутри. Спасибо, я и так достаточно страдал.

Но горячий тейк такой: AI в incident response не чинит плохой SRE-процесс. Он делает его быстрее, дороже и увереннее в своей неправоте.

1. Если нет SLO - агент не знает, что важно

AI может сгруппировать алерты и предложить гипотезу. Но он не знает, что для бизнеса больнее: 500 ошибок в админке или +800 ms на checkout.

Это всё ещё решают SLI/SLO и error budget. Без них agent будет сортировать шум по громкости, а не по impact. Получится быстрый дежурный без контекста.

2. Если телеметрия каша - AI будет гадать
OpenTelemetry semantic conventions - это база для корреляции: единые имена для traces, metrics, logs, profiles и resources. А log correlation позволяет связывать логи с traces через trace/span id.

Если в одном сервисе service, в другом app, в логах нет trace_id, владельцы живут в голове у Сережи, а деплои не связаны с инцидентами - агент будет играть в угадайку.

Сначала сделайте так, чтобы человек мог за 10 минут собрать timeline. Потом зовите AI ускорять это до одной минуты.

3. Давать write-права сразу - плохая идея

Вендоры уже говорят про approved remediations, rollback, scaling и автономные действия. Если сценарий типовой, зачем будить человека?

Но начинать надо не с "пусть сам чинит прод", а с read-only режима:
- собрать timeline;
- показать связанные алерты;
- найти похожие инциденты;
- подсветить последний deploy;
- предложить запросы к логам/трейсам;
- показать, какой runbook устарел.

Только потом - действия по allowlist: rollback canary, scale-up, рестарт consumer'а, отключение фиче-флага. И всё это должно попадать в аудит и постмортем.

Автономность без guardrails - это chaos engineering без календаря.

4. "AI написал RCA" - ещё не RCA

Root cause без доказательств - это не root cause, а уверенный autocomplete.

Нормальный AI-помощник должен показывать evidence: какая метрика изменилась, какой trace это подтверждает, какой deploy был рядом, какие логи связаны тем же trace_id.

Если агент не показывает доказательства - его выводы нельзя использовать для remediation. Максимум - как гипотезу для on-call.

5. AI не убирает toil автоматически

Catchpoint SRE Report 2026 охлаждает хайп: median toil у инженеров вырос до 34%. Почти половина респондентов говорит, что AI снизил toil, но треть не видит изменений, а часть получила новую нагрузку.

Самый неприятный пункт: только 13% уверены, что могут мониторить reliability AI/ML-компонентов.

То есть менеджмент уже видит "AI transformation", а инженер в 3 ночи всё ещё проверяет, не наврал ли ему новый помощник. Красота.

Что я бы мерил перед внедрением AI SRE:
- минуты от page до первого нормального timeline;
- процент алертов с владельцем, severity и runbook;
- сколько алертов агент сгруппировал правильно, а сколько спрятал зря;
- сколько раз AI-сводка сократила расследование или добавила проверки;
- сколько remediation-действий прошли без отката.

И только после этого можно говорить, что AI помогает reliability, а не просто красиво пересказывает дашборды.

AI SRE Agent - это не замена on-call. Это усилитель для команды, у которой уже есть SLO, нормальная телеметрия, runbook'и, ownership и культура постмортемов.

Если этого нет, AI станет новым участником инцидента. С доступом к продакшену. Что может пойти не так?

Вопрос к вам: вы бы пустили AI-агента в свой on-call хотя бы в read-only режиме?

#sre #observability #oncall #ai #incidentresponse