ИИ-агенты для SRE переходят из разряда красивых демонстраций в вполне прикладной инструмент для дежурств. The New Stack опубликовал спонсорскую колонку PagerDuty о пяти сценариях, где агентам отдают рутинную работу по инцидентам, а инженерам оставляют решения с риском и архитектурой.
Для русскоязычных DevOps- и SRE-команд тезис здесь приземлённый: речь не про «ИИ поверх всего», а про меньшее число ручных разборов алертов, однотипных перезапусков и ночных действий по инструкции. Если подход взлетит, выигрыш будет не в модном ярлыке, а в сокращении времени на рутину и зависимости от пары самых опытных дежурных.
PagerDuty продвигает узкие сценарии вместо автопилота
Автор материала — Mandi Walls, DevOps-евангелист PagerDuty. Это важная оговорка: колонка не притворяется независимым исследованием и прямо продвигает взгляд вендора на рынок. Но сам тезис звучит здраво: эффект появляется не тогда, когда компания прикручивает ИИ ко всему стеку сразу, а когда агенту дают один понятный сценарий в управлении инцидентами.
В тексте перечислены пять ролей. Первая — автономная обработка знакомых инцидентов: агент получает сигнал, сопоставляет его с контекстом и выполняет типовой набор действий. Вторая — работа как «оперативная память» команды: агент использует историю прошлых аварий, связанные сигналы и уже проверенные шаги, чтобы не зависеть от того, на смене ли нужный эксперт.
Третья роль отделяет агентный подход от обычной автоматизации. Скрипт ждёт заранее заданный триггер. Агент, по логике статьи, сам решает, что проблема относится к низкорисковому классу и её можно исправить без участия человека. Четвёртая роль — освобождение времени SRE для улучшения архитектуры и наблюдаемости вместо бесконечного тушения пожаров. Пятая — смещение инженеров в сторону проектирования контекста: они задают инструменты, ограничения и рамки безопасных действий, а не вручную вводят команды в терминале.
Главный спор не про ИИ, а про доверие к автономным действиям
Самая полезная мысль в колонке — не технологическая, а организационная. Если runbook перестаёт быть шпаргалкой для уставшего дежурного и становится набором правил для машины, компании придётся гораздо жёстче описывать допустимые действия в продакшене. И тут выясняется, насколько хорошо у команды вообще формализованы знания об инфраструктуре.
Walls формулирует проблему прямо: ограничение доли рутинной работы не решает саму рутину. В оригинале это звучит так: нагрузка никуда не исчезает, её лишь ограничивают, а не устраняют. Для рынка это важнее любого модного слова. Если у команды половина времени уходит на ручное восстановление сервисов, ИИ полезен не потому, что он «умный», а потому что он может снять повторяемую механическую часть работы.
Но здесь же и главный риск. Материал описывает желаемую траекторию рынка, а не подтверждённую статистикой практику. Между «автономно перезапустить сервис» и «автономно не усугубить аварию» лежит довольно дорогая зона ответственности. Поэтому для большинства компаний реалистичный сценарий на ближайший год — не полный автопилот, а аккуратные агенты с узкими правами, журналом действий и жёсткими ограничениями.
Что это значит для российских SRE-команд
Для российских и СНГ-команд ценность здесь в дефиците сильных SRE и росте сложности инфраструктуры. Когда экспертов мало, а сервисов много, историческая память по инцидентам становится почти таким же активом, как код и инфраструктура. Агент, который умеет быстро поднять контекст по прошлым сбоям и выполнить безопасный шаблон действий, может снизить нагрузку на дежурства и сократить время восстановления.
Но покупать очередной ИИ-модуль ради презентации бессмысленно. Рабочая модель начинается с другого: нормальных runbook, понятных правил эскалации, качественной телеметрии и списка операций, которые действительно безопасно автоматизировать. Иначе ИИ в эксплуатации останется дорогим декоративным слоем над тем же самым хаосом.
Следующий логичный шаг для рынка — пилоты на одном-двух низкорисковых сценариях, где можно быстро проверить, уменьшает ли агент реальную дежурную рутину, а не только добавляет новый интерфейс к старым проблемам.