Сбой поиска Microsoft 365 MO1456424: причина, затронутые сервисы и последствия

Инцидент Microsoft 365 MO1456424 начался 17 августа 2026 года в 08:46:14 UTC. Microsoft классифицировала его как деградацию сервиса: часть пользователей столкнулась с проблемами при поиске в SharePoint Online, OneDrive, Outlook в браузере и настольном Outlook. Доступная запись об инциденте не указывает время его окончания.

Какие сервисы и пользователи пострадали

Проблема касалась именно поиска: затронутые пользователи не всегда могли найти письма, документы и другой контент в перечисленных приложениях Microsoft 365. В уведомлениях Microsoft говорится о «некоторых пользователях», но количество клиентов не приводится.

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

Это не означает, что все функции Outlook, SharePoint Online или OneDrive перестали работать. Однако невозможность быстро найти письмо или файл способна заметно нарушить рабочий процесс сразу в нескольких сервисах.

Что стало причиной MO1456424

Microsoft сообщила, что недавнее развёртывание внесло «проблему неэффективного использования ресурсов» в инфраструктуру, обрабатывающую поисковые запросы. Проще говоря, после изменения поисковая система стала нерационально расходовать доступные ресурсы и хуже справляться с частью запросов.

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

Важно и то, чего в опубликованных материалах нет: они не указывают на кибератаку, подтверждённый сбой сети в определённом регионе или единую проблему с пропускной способностью всей платформы Microsoft 365.

Как Microsoft исправляла проблему

Компания заявила, что разработала и развёртывала исправление, призванное снизить давление на ресурсы и восстановить работу поиска. Другие сообщения также описывали решение как исправление неэффективности, появившейся после недавнего изменения, с последующим возвращением сервисов к нормальной работе.

При этом доступная запись MO1456424 по-прежнему не содержит времени завершения. Она не позволяет установить, когда исправление было полностью применено ко всем затронутым пользователям. В материалах также нет указаний на откат обновления, постоянную перестройку архитектуры или более детальное описание технического решения.

Почему это назвали инцидентом, если статус — «деградация сервиса»

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

Microsoft отдельно не объясняла, почему выбрала именно такую классификацию. Наиболее точная трактовка — буквальная: это была многопродуктовая деградация поиска для части пользователей, а не недоступность всех сервисов Microsoft 365.

Как MO1456424 соотносится с другими сбоями

Несколько заметных проблем произошли примерно в тот же период, но их причины и масштабы различались.

GitHub: отдельный сбой продолжительностью 7 часов 47 минут

17 августа 2026 года GitHub пережил отдельный инцидент с 13:28 до 21:15 UTC — всего 7 часов 47 минут. На пике доля ошибок в веб-интерфейсе и API составляла примерно 20%, а для загрузки архивов и необработанного содержимого — около 50%. Были затронуты Issues, pull requests, API, Actions и Copilot.

По данным GitHub, причиной стали перегруженные балансировщики нагрузки, ошибочная политика автоматического масштабирования и скрытая ошибка повторных запросов в Visual Studio Code. Эти механизмы отличаются от проблемы с поисковой инфраструктурой, вызванной развёртыванием в MO1456424.

Предыдущие сбои поиска Microsoft 365

Проблемы с поиском в Microsoft 365 уже возникали ранее. В апреле 2025 года пользователи Outlook в браузере и SharePoint Online сталкивались с задержками и ошибками, связанными с инфраструктурными компонентами, обрабатывавшими поисковые запросы и работавшими ниже допустимых показателей производительности.

Отдельно сообщалось о сбоях поиска файлов в OneDrive: результаты могли отображаться пустыми или не показывать файлы, которые пользователь точно загружал. Однако имеющиеся материалы не подтверждают, что у этих проблем была та же первопричина, что и у MO1456424.

Июльская авария Azure и Microsoft 365

Сбой 23 июля 2026 года был шире по охвату и технически отличался от MO1456424. Согласно истории статуса Azure, с 14:44 до 19:41 UTC часть клиентов испытывала проблемы с подключением, повышенную задержку или сложности с доступом к сервисам, размещённым в регионе West US. Ограничения касались трафика, входившего в регион или выходившего из него; трафик, полностью остававшийся внутри региона, не затрагивался.

Microsoft связала ту аварию с ошибкой автоматизированной системы сетевого обслуживания: она удалила IP-маршруты с большего числа устройств, чем предполагалось. Это был сбой сетевого управляющего контура, а не деградация поискового сервиса, как в случае MO1456424.

Что эти события показывают — и чего не доказывают

Вместе эти инциденты относятся к разным уровням эксплуатации облачных платформ:

• MO1456424: недавнее развёртывание привело к неэффективному использованию ресурсов поисковой инфраструктурой.
• Сбой GitHub 17 августа: сочетание перегрузки балансировщиков, ошибки автомасштабирования и проблемы с повторными запросами.
• Июльская авария Azure: ошибка автоматизированного сетевого обслуживания привела к удалению лишних IP-маршрутов.

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

Доступные отчёты также не доказывают, что именно рост нагрузки со стороны искусственного интеллекта стал причиной MO1456424, сбоя GitHub или июльской аварии Azure. GitHub действительно рассказывал о миграции из небольших собственных дата-центров в публичное облако и о движении к мультоблачной архитектуре, однако сами по себе эти стратегические планы не устанавливают причинную связь с конкретным сбоем.

Более осторожный вывод таков: по мере того как облачные сервисы и связанные с ИИ рабочие нагрузки становятся всё важнее, возрастает значение безопасного развёртывания, планирования мощностей, защиты от лавины повторных запросов, изоляции отказов и тщательного тестирования сетевой автоматизации. Мультоблачная модель способна распределить часть инфраструктурных рисков, но автоматически не предотвращает сбой внутри управляющего контура самого сервиса.