AI SRE-агенты уже умеют помогать с расследованием сбоев, но в большинстве случаев всё ещё ждут ключевого решения от человека: считать ли ситуацию инцидентом и начинать ли разбор. Именно эту границу между ассистентом и самостоятельным оператором предлагает обсудить компания Traversal на вебинаре 22 октября 2026 года. Для российских команд это полезная поправка к маркетингу вокруг AIOps: бот, который красиво отвечает в чате, ещё не заменяет on-call-инженера.
Об этой модели трёх этапов автономности сообщает The New Stack. Спикером выступит Рааз Двиведи — сооснователь и CTO Traversal, а также доцент Cornell Tech. Материал опубликован при поддержке Traversal, поэтому его стоит читать не как независимое исследование рынка, а как внятно сформулированную позицию поставщика инструмента для работы с инцидентами.
Первый этап авторы называют invoked, то есть «по вызову». Это привычные copilots, чат-интерфейсы и CLI: инженер видит проблему, открывает инструмент, задаёт вопрос и получает помощь в поиске причины. Польза очевидна — быстрее собрать контекст, сопоставить сигналы и не листать вручную десятки дашбордов. Но триггер остаётся человеческим: если никто не заметил симптом или не решил спросить систему, агент молчит.
Второй этап — background. Здесь автоматизация уже работает в фоне: по расписанию, правилам алертов или заранее заданным условиям. Такой подход знаком любой зрелой эксплуатации: мониторинг фиксирует превышение порога, правило создаёт уведомление, сценарий запускает диагностику. Система действует раньше человека, но не принимает самостоятельного решения о том, что именно требует внимания. Человек всё равно проектирует пороги, правила и перечень допустимых реакций — а затем разбирается с ложными срабатываниями.
Автономность начинается не с ответа, а с инициативы
Третий этап — proactive: агент сам определяет, что ситуация похожа на инцидент и её нужно исследовать, не дожидаясь запроса инженера, расписания или заранее сработавшего триггера. В этом и состоит неудобный для рынка вопрос. Генеративная модель может быстро сформулировать гипотезу по логам и метрикам; гораздо сложнее доверить ей решение прервать дежурного, начать цепочку действий или изменить состояние production-системы.
Двиведи связывает следующий шаг с причинным ИИ и агентным рассуждением при анализе production-инцидентов. Формулировка важна: речь идёт не просто о суммаризации событий. Чтобы проактивный агент был полезен, ему нужен контекст зависимостей, понимание нормального поведения сервиса и возможность отличать причину от совпадающего симптома. Иначе он лишь создаст ещё один источник уведомлений — дорогой, разговорчивый и, вероятно, уверенный в себе.
Traversal заявляет, что её Workers уже работают на проактивном конце этой шкалы. Однако в опубликованном анонсе нет независимых метрик точности, числа предотвращённых инцидентов или сравнения с другими продуктами. Это не обесценивает саму модель трёх этапов, но не позволяет делать вывод о том, насколько хорошо конкретный инструмент справляется с автономным обнаружением проблем.
Практический вывод для руководителей платформенных и SRE-команд довольно приземлённый. При оценке AI-инструмента стоит отделять четыре разные возможности: собрать сигналы, объяснить их, предложить действие и самостоятельно решить, когда запускать процесс. Первые две уже доступны во множестве решений. Третья требует ограничений на доступ и понятного процесса одобрения. Четвёртая требует ещё и доверия к качеству данных, наблюдаемости, истории инцидентов и правилам эскалации.
Для разработчиков это означает, что инвестиции в телеметрию, понятные ownership-границы сервисов и качественные runbook'и не становятся менее нужными из-за появления агентов. Наоборот, без этой основы у агента не будет надёжного контекста для решения. Для бизнеса вопрос тоже не сводится к сокращению времени реакции: неверно инициированный инцидент способен отвлечь команду, а неверно выполненное исправление — увеличить ущерб.
Следующий рубеж для AI SRE-агентов — не способность написать убедительное объяснение аварии, а прозрачность решения «пора вмешаться». Победят не те системы, которым формально дали больше прав, а те, чьи основания для эскалации и границы самостоятельных действий инженерная команда сможет проверить до первого ночного пейджинга.