Когда в продакшене срабатывает аварийное оповещение, самая опасная ошибка — принять симптом за настоящую причину. Если ИИ-агент действует по неверному диагнозу, это не просто тратит время инженеров, но и создает риск для всей системы. Alibaba представила фреймворк STAROps, который учит агентов не просто находить аномалии, а точно указывать на источник проблемы.
Обычно при оценке AgenticOps (подхода, где ИИ-агенты автоматизируют операции) внимание уделяют количеству инструментов, которые может использовать агент, или его способности запускать исправления. Однако Alibaba, разрабатывая STAROps, сосредоточилась на более фундаментальном вопросе: способен ли агент правильно определить первопричину? Оповещение обычно сообщает, какая метрика превысила порог, но не где именно произошел сбой. Например, ошибки 5xx могут указывать как на проблему во фронтенде, так и на медленную базу данных или исчерпание ресурсов ноды.
Текущие универсальные агенты могут запрашивать большой объем данных и генерировать хорошо структурированные отчеты, которые звучат правдоподобно. Но полный отчет не доказывает, что агент нашел объект, который действительно вышел из строя. Если он останавливается на сущности, где сработало оповещение, или принимает выраженную аномалию на пути распространения за первопричину, более сложные рассуждения могут сделать неверный вывод еще более убедительным.
Проверка концепции (proof of concept) обычно фокусируется на нескольких известных ошибках: зависший под, медленный SQL-запрос или сбой Redis. Это показывает, что система справляется со сценариями A, B и C, но не доказывает, что она сможет найти проблему типа D. В реальных продакшн-средах гораздо больше может пойти не так: проблема может возникнуть в приложении, контейнере, ноде, базе данных или сети. Топологии постоянно меняются, данные могут быть неполными, и несколько аномалий могут появиться одновременно.
STAROps решает эту проблему, сосредоточившись на самом процессе расследования: как агент понимает текущую систему, решает, что проверять дальше, доказывает надежность вывода и учится на сбоях в продакшене. Для этого фреймворк использует несколько ключевых механизмов:
- UModel — унифицированная модель системы. Она организует объекты и их взаимосвязи, такие как какие поды запускают сервис, к какому деплойменту относится под, на какой ноде он размещен и от каких баз данных зависит сервис. Это позволяет агенту точно знать, что он исследует, и следовать явным связям.
- Динамическая топология исследования — поверх UModel, STAROps поддерживает динамическую топологию, которая отслеживает проверенные объекты, найденные аномалии, подозреваемых кандидатов и необъясненные ветви. Этот граф служит картой расследования и записью процесса.
- RCA-Bench — специальный бенчмарк для оценки агентов анализа первопричин. Он включает 103 случая сбоев по 28 типам. Каждый случай фиксирует сущность первопричины, тип сбоя, путь распространения и ключевые доказательства. Оценивается, насколько точно агент нашел сущность первопричины, определил тип сбоя и поддержал расследование доказательствами.
- Обучение на продакшн-ошибках — STAROps сохраняет входные данные задачи, вызовы инструментов, результаты запросов, ошибки, доказательства, время выполнения и отзывы пользователей из продакшн-запусков. Низкооцененные или неудачные запуски становятся регрессионными тестами.
Результаты бенчмарка RCA-Bench, проведенного на стратифицированном наборе из 30 случаев, показывают превосходство STAROps над универсальным агентом OpenClaw + DeepSeek-V4-Pro. Общий балл STAROps составил 75.23 против 51.02 у конкурента. Ключевое отличие заключается в способности идентифицировать сущность первопричины: здесь STAROps набрал 90 баллов против 52.8, что на 70% выше. По типу сбоя разрыв составил 24.7 балла. Это показывает, что универсальные агенты могут проводить несколько раундов запросов, но STAROps лучше определяет, куда именно направить расследование.
Например, в случае падения трафика для сервиса product-catalog::ListProducts универсальные агенты ошибочно заключили, что проблема в балансировщике нагрузки или фронтенде. STAROps же проследовал по связям до ноды cn-hongkong.10.0.1.107, где использование CPU выросло до 99.98%, что и было истинной причиной. В другом случае, когда замедлился фронтенд POST /api/checkout, STAROps, в отличие от конкурентов, продолжил расследование по трассировкам и обнаружил медленный SQL-запрос в сервисе inventory.
STAROps от Alibaba наглядно демонстрирует, что для эффективного анализа первопричин критически важна не столько способность агента запускать множество инструментов, сколько его умение построить точную модель системы и на её основе отличить симптом от истинной причины. Однако в некоторых областях, таких как проблемы с трафиком, DNS, CDN и сторонними сервисами, фреймворку ещё предстоит совершенствоваться.