ИИ-агент Автоматизация Новости 13.07.2026 чтения обновлено 01.01.1970

Brain: как ИИ решает, что Azure официально упал

Microsoft открыла детали Brain — внутренней AIOps-системы, которая следит за состоянием Azure, сама распознаёт инциденты и оповещает пострадавших клиентов. Без ручного дежурства: ИИ ставит диагноз и останавливает рискованные обновления.

Андрей Сарапулов редактор Источник

Brain: как ИИ решает, что Azure официально упал

Коротко

Brain — централизованная AIOps-система Microsoft, которая непрерывно мониторит состояние Azure и самостоятельно принимает решения: объявляет инциденты, останавливает проблемные развёртывания и уведомляет затронутых клиентов. Система работает поверх Azure Resource Graph, формируя цифровой двойник облака в реальном времени. По словам CTO Марка Руссиновича, Brain охватывает 70–80% критических сервисов и сокращает количество клиентских обращений в поддержку в четыре-шесть раз.

Microsoft открыто рассказала о Brain — внутренней системе, которая непрерывно следит за состоянием Azure и всё чаще действует сама: объявляет инциденты, останавливает вредоносные обновления и уведомляет пострадавших клиентов без участия человека.

CTO Azure Марк Руссинович впервые описал систему в серии публикаций об инструментах надёжности Azure. Чтобы разобраться подробнее, редакция The New Stack поговорила с ним напрямую — о том, как Brain появился и как менялся со временем.

По описанию Microsoft, Brain — это централизованная AIOps-система для мониторинга здоровья облака. Она работает как интеллектуальный слой поверх Azure Resource Graph (ARG), и вместе они образуют цифровой двойник Azure в реальном времени.

Цифровой двойник в реальном времени

Brain активно использует ИИ-инструменты, но сам проект куда старше генеративного ИИ. Фундаментом стал Azure Resource Graph. «В основе системы лежит Azure Resource Graph, который начинался как идея создать цифровой двойник Azure, чтобы понимать связи между разными ресурсами», — рассказывает Руссинович.

Этот внутренний двойник превратился в публичный сервис по запросу крупных корпоративных клиентов — тех, у кого огромные инфраструктуры, раскиданные по множеству тенантов и подписок. Им нужны были простые запросы вроде «Какие Linux-виртуалки у меня есть и какие версии ОС на них стоят?»

Анализ первопричин на основе этого графа стал отправной точкой для Brain. «Часто можно просто проследить зависимости и сказать: эти сервисы зависят от вот этого, который стал нездоровым. Думаю, именно это и стало толчком к тому, чтобы Brain начал применять ML-алгоритмы для поиска первопричин поверх графа», — объясняет Руссинович.

Параллельно Microsoft столкнулась с типичным разрывом в измерениях: собственные метрики команды сервиса показывают зелёный, а клиенты видят сбои. По словам Руссиновича, это происходило потому, что команды либо измеряли не то, что реально испытывают пользователи, либо агрегировали данные так, что проблемы конкретных клиентов просто терялись в усреднённых показателях.

Решением стала стандартизация. «Мы решили договориться о единых способах измерения здоровья и разработали индикаторы уровня сервиса — SLI», — говорит Руссинович. Добиться того, чтобы все сервисы Azure реально их отдавали через общие библиотеки с единой схемой, заняло несколько лет.

Три источника сигналов

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

Azure работает в более чем 80 регионах, свыше 500 дата-центрах и опирается на более чем 800 000 километров оптоволоконных и подводных кабелей. И при этом Microsoft всё равно иногда узнавала о тихо деградирующем сервисе от клиента раньше, чем от собственных систем.

Сегодня Brain получает данные из трёх классов сигналов. Первый — стандартизированные SLI. Второй — собственные мониторы команд сервисов: они регистрируются отдельно и работают рядом с телеметрией развёртываний, объёмом обращений в поддержку и сигналами межсервисных зависимостей. Третий — сторонние индикаторы.

На основе этих данных Brain формирует четыре вывода для любого объекта — будь то сервис, регион, единица развёртывания или ресурсы конкретного клиента. Система сообщает о состоянии здоровья, серьёзности проблемы, круге пострадавших и объясняет, почему пришла к такому выводу.

Эти выводы запускают алерты и автоматические действия. Brain объявляет инциденты исходя из масштаба поражения, ограничивает уведомления клиентов только затронутыми подписками и регионами, автоматически направляет инциденты нужной команде и отправляет сигналы для остановки развёртываний, которые вызвали проблему.

Почему пороги задаёт ML, а не люди

Изначально Microsoft планировала действовать по учебнику: попросить каждую команду сервиса самостоятельно определить SLO. Не сработало. По словам Руссиновича, согласовать схему было уже непросто, но «ещё сложнее — придумать SLO, который действительно хорош». Команды намеренно занижали пороги, чтобы реже получать алерты.

«Все хотят быть очень консервативными, потому что не хотят, чтобы их будили по ночам… поэтому мы решили просто перестать просить их определять SLO.»

Теперь ML-модели сами выводят пороги из поведения каждого сервиса — отдельно для каждой единицы масштабирования и каждого региона. «Есть базовая линия поведения сервиса в этом регионе по сравнению с тем, и тогда мы видим, когда появляются регрессии», — говорит Руссинович. Полученные SLO динамически корректируются без ручного вмешательства.

Связать регрессию с конкретным изменением ещё сложнее. Brain отслеживает развёртывания обновлений сервисов, и «у нас есть ML-алгоритмы, которые с определённой уверенностью могут сказать: вот это развёртывание вызывает регрессию». Но последнее обновление, добравшееся до единицы масштабирования, не обязательно виновато. «Изменение не всегда проявляется как регрессия сразу. Может быть задержка — несколько часов или даже дней. А за последние сутки могло произойти очень много развёртываний — и вопрос: которое из них?»

Агенты, которые устраняют инциденты

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

По его словам, автоматические уведомления дали «сокращение клиентских обращений в поддержку в четыре-шесть раз — потому что Brain сам их уведомляет, и они знают, что мы уже занимаемся проблемой».

«Как только в цепочку попадает человек, эти 15 минут можно легко пропустить.»

«Наша цель по времени устранения — 15 минут: от момента возникновения проблемы до её решения», — говорит Руссинович. По его словам, для 80–90% сервисов, подключённых к Brain, этот норматив выполняется. Нередко всё укладывается в пять минут.

Оговорка: Brain охватывает пока не всё. Microsoft сосредоточилась на критических сервисах — тех, от которых зависит остальной Azure. По оценке Руссиновича, покрытие составляет около 70–80% из них, остальные в работе.

Инженерам, которых всё же вызывают на инцидент, Brain сразу собирает картину, которую раньше приходилось складывать вручную. «Инцидент сразу наполняется автоматически собранной информацией: вот графики доступности по этому SLI по единицам масштабирования за последние 24 часа, вот список пострадавших клиентов, вот единица масштабирования, вот дополнительные данные. Уже на этом этапе инженер экономит огромное количество времени — вся информация перед ним, и не нужно её собирать самому.»

Агенты поверх Brain

Руссинович пишет, что «агентам нужно, на что быть агентными». Агент триажа без знания графа зависимостей не может ничего классифицировать — модель здоровья здесь предпосылка, а не следствие агентных операций в таком масштабе.

Microsoft уже запустила агентов поверх Brain. Система Triangle, описанная также в исследовательской статье Microsoft Research 2025 года, даёт каждой команде сервиса LLM-агента, обученного на исторических инцидентах и руководствах по устранению неполадок. Оркестратор маршрутизирует неоднозначные инциденты между ними.

«В Triangle у каждого сервиса есть агентный представитель. Оркестратор Triangle рассылает инцидент и говорит: "Вот инцидент — поднимите руку, если думаете, что это ваше"», — объясняет Руссинович. Без этого тикеты кочевали бы от команды к команде — то, что в Microsoft называют handoffs, — увеличивая время реакции. Инструменты ИИ-агентов всё активнее применяются именно для таких задач маршрутизации и триажа.

Triangle пока на раннем этапе. «Мы всё ещё в начале пути, подключено лишь небольшое число сервисов, но уже для них переключения между командами стали значительно быстрее и точнее, чем до Brain», — говорит Руссинович.

В долгосрочной перспективе он хочет, чтобы агенты заменили детерминированные правила устранения неполадок, которые команды пишут вручную. «Не нужно прописывать каждое правило в явном виде и строить дерево решений — пусть агент действует на основе собственного суждения. Это даёт массу преимуществ: система сама обновляется, а ещё может находить пути к решению, которые мы упустили бы в детерминированных правилах.» Об агентах, которые реально устраняют проблемы, он говорит прямо: «Мы всё ещё считаем себя в самом начале этого пути.»