Сбой Microsoft 365 23 июля 2026 года начался не из-за атаки и не из-за отказа железа, а из-за ошибки во внутренней автоматизации Microsoft. Компания в предварительном разборе инцидента объяснила: во время плановых работ система ошибочно сняла IP-маршруты с большего числа сетевых устройств, чем требовалось, и этого хватило, чтобы задеть Azure и сервисы Microsoft 365. Для ИТ-команд вывод простой: даже у крупнейшего облачного провайдера самый неприятный отказ может начаться с неудачного изменения в инфраструктуре.
По данным Microsoft, инцидент стартовал 23 июля в 10:44 по восточному времени США, или в 14:44 UTC. На пике, в 11:11 ET, сервис Downdetector зафиксировал 2403 жалобы при обычном фоне около 29. Больше всего обращений пришлось на SharePoint, далее шли Excel и Microsoft 365 Admin Center.
Сбой начался в регионе West US и быстро задел облачные сервисы
Microsoft вела инцидент Microsoft 365 под номером MO1437424, а на стороне Azure он проходил как ZJV6-SGG. Сильнее всего пострадали клиенты, чей трафик проходил через сетевую инфраструктуру Azure в регионе West US. Это важно: проблема была не в конкретном приложении, а в сетевом слое, через который пользователи добирались до сервисов.
В списке пострадавших были SharePoint Online, OneDrive, Teams, Microsoft 365 Admin Center, Power Automate, Copilot Chat, Microsoft Loop, Fabric, Power BI, Power Apps, Copilot Studio, Windows 365 и Microsoft Defender. Отдельно Microsoft перечислила затронутые сервисы Azure, включая Azure App Service, Application Gateway, Azure AI Search, Azure API Management, Azure Cosmos DB, Azure Databricks, Azure Firewall, Azure Kubernetes Service, Azure Monitor, Azure Virtual Desktop, ExpressRoute, Log Analytics, Microsoft Graph, Microsoft Sentinel, Virtual WAN и VPN Gateway.
Причиной стала ошибка в системе выполнения плановых работ
По предварительному разбору Microsoft, во время планового обслуживания в West US инженеры изолировали часть сетевых путей. В нормальном сценарии система переводит заявку на работы в машинные инструкции и проверяет, что хотя бы один из двух резервных путей остается доступным. Но в этот раз ошибка в системе обработки заявки добавила в зону работ лишние устройства.
Из-за этого между дата-центром West US и глобальной WAN-сетью Microsoft сняли IP-маршруты с большего числа устройств, чем планировалось. Входящий и исходящий трафик начал теряться, тогда как внутренний трафик внутри региона, по словам компании, не пострадал. Иначе говоря, вычисления и базы данных могли формально работать, но доступ к ним снаружи становился нестабильным или пропадал вовсе.
Откат занял меньше часа, полное восстановление растянулось дольше
Сначала Microsoft пыталась смягчить последствия, перенаправляя трафик по альтернативным путям. Это помогло лишь частично. После привязки сбоя к недавнему сетевому изменению компания начала откат в 13:45 ET и завершила его в 14:26 ET.
Восстановление Microsoft 365 подтвердили телеметрия и отчеты клиентов вскоре после отката, но часть сервисов Azure приходила в себя дольше. Полное восстановление всех затронутых облачных сервисов Microsoft зафиксировала к 15:41 ET. Для бизнеса это типичный неприятный сценарий: первопричину уже убрали, а зависимые сервисы еще догоняют нормальное состояние.
Для рынка это напоминание не верить в облако «по умолчанию»
Для российских и СНГ-команд, которые строят архитектуру вокруг Microsoft 365, Azure или гибридных каналов доступа, здесь один практический вывод: резервирование не спасает, если ошибка заложена в самом механизме внесения изменений. Поэтому стоит отдельно проверять не только основные приложения, но и вход в Microsoft 365, административные панели, Microsoft Graph, ExpressRoute, VPN и другие реальные зависимости бизнеса. Если план обеспечения непрерывности и аварийного восстановления исходит из логики «облако не падает», это слабый план.
Microsoft обещает выпустить финальный Post Incident Review после полного внутреннего разбора; главный вопрос теперь не в том, какой именно сценарий дал сбой, а сколько независимых проверок нужно автоматизации, чтобы плановые работы не превращались в региональный отказ.
Источники: BleepingComputer, Azure Status History, Network World.