Когда музыкальный сервис обрабатывает сотни миллионов запусков в день, любой сбой превращается не в один красный алерт, а в поток логов, метрик и обращений пользователей. Китайская Migu Music решила отдать первичный разбор таких инцидентов ИИ-агентам. Это не история про генерацию музыки: здесь ИИ работает внутри эксплуатации — там, где нужно быстро понять, почему сервис начал ломаться.

Почему кейс Migu Music вообще важен

По данным Migu Music и Huawei Software, платформа обслуживает 470 млн пользователей видеорингтонов и более 800 млн воспроизведений в сутки. Для такой нагрузки характерны пики, множество микросервисов и два разных сетевых контура — интернет и телеком. При сбое инженеру приходится сопоставлять мониторинг, трассировки, логи, изменения в релизах и бизнес-метрики. Скорость восстановления зависит не только от умения исправить проблему, но и от того, как быстро команда сузит поиск.

Что именно сделали Migu и Huawei

Партнёры называют решение Lewei Intelligent Software O&M Agents. Его рабочий цикл построен из четырёх шагов: восприятие сигнала, анализ контекста, выбор решения и исполнение. Агент собирает технические данные из рабочей среды, сопоставляет их с накопленными знаниями и помогает команде перейти от отдельного алерта к объяснимой гипотезе о причине инцидента.

Важный нюанс: в исходном материале речь идёт не о «роботе, который сам чинит всё без контроля». Авторы описывают движение от анализа к совместному исполнению и непрерывной доработке в реальной среде. То есть агенту нужны качественные данные, заданные границы действий и проверка результатов со стороны инженеров.

Чем это отличается от обычного AIOps

Традиционный AIOps обычно ищет аномалии, связывает алерты и помогает анализировать неисправности. Агентный подход добавляет целевую многошаговую работу и вызов инструментов: не только заметить симптом, но и собрать контекст, предложить следующий безопасный шаг, а в разрешённом сценарии — выполнить его. Huawei подчёркивает, что система должна адаптироваться по мере изменения процессов, архитектуры и накопления операционного опыта.

Какие результаты заявляют компании

В релизе Migu Music и Huawei Software сообщают о стопроцентной наблюдаемости цепочки операций, поиске критической неисправности в среднем менее чем за пять минут и сокращении MTTR — среднего времени восстановления — на 60%. Это данные участников проекта, а не независимое исследование, поэтому их нельзя переносить на любой сервис. Но сама цель понятна: приблизиться к модели «1–5–10» — обнаружить проблему за минуту, локализовать за пять и восстановить работу за десять.

Что можно повторить у себя

  • Начните не с автономного исправления, а с разбора повторяющихся инцидентов и подготовки понятного отчёта для дежурного инженера.