Azure SRE Agent внутри Microsoft уже обработал более 1,8 млн инцидентов, а часть команд доверяет ему больше половины типовых сбоев без участия человека. Для русскоязычных SRE, DevOps и IT-директоров это не история про «чатбота для алертов», а про сдвиг в операционной модели: агент делает рутину, человек задает правила игры.
Microsoft продвигает подход «agents operate, humans govern» — агенты работают, люди управляют, сообщает The New Stack. В материале речь идет о Azure SRE Agent: сервисе для расследования инцидентов, поиска причин, автоматизации runbook-сценариев, подготовки исправлений и запуска безопасных действий вроде рестарта, масштабирования или отката релиза.
Главный тезис простой и довольно болезненный для любой команды с ночными дежурствами: инженеры тратят слишком много времени не на развитие систем, а на их обслуживание. Типичный сценарий знаком до зевоты: 3 часа ночи, пейджер, несколько дашбордов, логи, телеметрия, тикеты, подозрение на ложное срабатывание и попытка понять, кого еще будить. Агент в этой схеме должен не заменить SRE как профессию, а забрать первый слой расследования: собрать контекст, сопоставить сигналы, найти вероятную причину и предложить действие.
По данным The New Stack, внутри Microsoft более 3 000 сервисных команд уже используют агент для расследования проблем, root cause analysis, реагирования на инциденты, исправления кода, автоматической митигации, проактивного обнаружения и отчетности. Объем тоже не лабораторный: более 1,8 млн инцидентов прошли через систему, многие были смягчены за минуты. Для некоторых внутренних команд, по словам Шамира Абдула Азиза, lead program manager по продукту, более половины инцидентов автономно ведет агент — но только там, где речь идет о заранее описанных безопасных операциях.
Вот здесь начинается важная часть, которую легко пропустить за красивой вывеской AIOps. Microsoft не предлагает включить агенту полный доступ к продакшену и пожелать всем спокойной ночи. Управление строится вокруг identity, RBAC, политик доступа к инструментам и approval-процессов. Одни действия можно разрешить автоматически, другие — только после пошагового подтверждения, третьи — заблокировать. В статье приводится показательный пример: агент может получить право удалить поврежденный индекс в SQL-таблице, но не удалить саму таблицу. Это уже не «ИИ что-то решил», а программируемая система допусков.
Технически агент заточен под Azure, но не замкнут только на Azure. Он получает нативный доступ к Azure Monitor, Application Insights, Log Analytics и Azure Resource Graph. Дополнительно предусмотрены коннекторы к Azure DevOps и GitHub, а через MCP — к внешним источникам вроде Google Drive, Confluence, Cursor, Claude Code и другим инструментам. Идея в том, что без контекста агент остается дорогим интерфейсом к логам. С контекстом о подписках, телеметрии, коде, runbook-файлах и внутренних правилах он начинает понимать, как именно работает конкретная организация.
Отдельный акцент Microsoft делает на том, что зрелость здесь не в промптах, а в «обвязке»: проверке, аудите, оценке качества, телеметрии, метриках и воспроизводимости решений. Абдул Азиз называет это переходом от prompt engineering к context engineering, а затем к harness engineering — системе, которая позволяет запускать агентов в масштабе и контролировать их поведение. Для бизнеса это важнее, чем очередная демонстрация магии на сцене: если агент утверждает, что исправил проблему, платформа должна позволять проверить это утверждение.
В статье есть и клиентские метрики. У компании InEight, по данным The New Stack, использование такого подхода дало сокращение времени расследования инцидентов и triage build failure на 80%, снижение усилий на расследование багов на 67% и уменьшение стоимости на 84%. Цифры звучат вкусно, но к ним стоит относиться как к результату конкретной реализации, а не универсальному SLA от Microsoft. Почти наверняка за ними стоят хорошо описанные процессы, доступ к данным, дисциплина в runbook-документации и политическая воля дать агенту реальные права, а не только окно чата.
Для разработчиков и платформенных команд практический вывод довольно трезвый: агенту бесполезно скармливать хаос и ждать порядка на выходе. Если алерты шумят, ownership ресурсов неясен, знания живут в головах трех старших инженеров, а runbook последний раз обновляли при переезде с Jenkins, автономность быстро упрется в стену. Microsoft прямо советует не использовать агент там, где достаточно одной детерминированной команды или простого фильтра. Логика звучит здраво: оркестрируйте, а не считайте токенами то, что прекрасно делает скрипт.
Есть и организационный эффект. Если код все чаще пишут агенты, операционная нагрузка будет расти: больше pull request, больше изменений, больше зависимостей, больше странных сбоев на стыке систем. Vyom Nagrani из команды продукта формулирует это жестко: если агенты пишут код, другому агенту придется его эксплуатировать. Но ждать полной «агентной разработки» необязательно — те же механики уже применимы к коду, который написали люди.
Для российских и русскоязычных команд прямое использование продукта может зависеть от облачной стратегии, юридических ограничений и доступности Azure в конкретной юрисдикции. Но сама модель шире одного вендора. Инцидентная рутина, ручной разбор логов, согласования между командами и вечные «а кто владелец этого сервиса?» одинаково болят в банках, ретейле, телекоме, SaaS и госсекторе. Если агентная эксплуатация станет нормой, конкурентным преимуществом окажется не наличие ИИ-кнопки, а качество операционного контекста: телеметрия, права, документация, трассировка решений и понятные границы автономии.
Azure SRE Agent сейчас выглядит не как замена дежурного инженера, а как экзамен для всей SRE-практики компании. Агент быстро покажет, где у команды порядок, а где знания держатся на устной традиции и героизме ночной смены. И главный вопрос теперь не в том, можно ли доверить ИИ рестарт сервиса, а в том, достаточно ли хорошо вы описали систему, чтобы доверять собственным правилам: .