Глобальный сбой Microsoft, начавшийся в четверг, 12 ноября, вывел из строя заметную часть сервисов Microsoft 365: почту, облачные и ИИ-инструменты. Из-за проблем остановились привычные рабочие процессы у компаний, больниц, ведомств и судов — наглядный урок для любой команды, которая считает одного облачного поставщика достаточным планом непрерывности бизнеса.
По данным Ars Technica, Microsoft не нашла признаков злонамеренной активности. Компания связала инцидент с тем, что часть инфраструктуры не проходила автоматические проверки состояния: серверы исключались из работы, нагрузка росла в нескольких регионах, а доступная ёмкость сокращалась. То есть причиной стала не атака и не всплеск пользовательского трафика, а сбой в механизме, который должен был вовремя замечать проблемы и изолировать их.
Перебои продолжались и в пятницу утром. Microsoft сообщила, что расширила тайм-аут доставки электронной почты до 48 часов, чтобы сохранить задержанные письма и не допустить их потери. Для пользователей это означает не просто медленный Outlook: письмо может уйти, но входящее сообщение, код подтверждения или уведомление от партнёра прийти с существенной задержкой. Для организаций, завязанных на почтовые согласования и многофакторную аутентификацию, такой режим быстро превращается в операционный стоп-кран.
Масштаб последствий был далёк от обычного корпоративного «не открывается календарь». В Японии сбой затронул государственную ИТ-инфраструктуру. Больницы, полиция, школы и бизнесы искали обходные процедуры; в отдельных случаях врачи не могли отправить пациентам важные обновления по лекарствам и дальнейшему лечению. Финансовые операции тоже пострадали: клиенты не получали одноразовые коды и не могли подтвердить банковские переводы. В Верховном суде Филиппин нарушилась юридическая работа, а офис шерифа в штате Колорадо сообщил о сложностях с оформлением залога для немедленного освобождения заключённых.
Почему восстановление оказалось таким сложным
После обнаружения проблемы Microsoft пыталась не допустить отключения новых серверов и параллельно проверяла альтернативные способы оценки их состояния. Однако примерно через четыре часа стало понятно, что локальной правкой дело не ограничится. Компания обнаружила перегрузку базового процесса на затронутых серверах: она съедала доступную мощность. В качестве варианта восстановления инженеры изолировали часть инфраструктуры, перезапускали компоненты и возвращали трафик постепенно, чтобы проверить стабильность до развёртывания изменений шире.
Эта схема звучит разумно, но в реальном инциденте дала неприятный эффект: некоторые возвращённые серверы снова переставали отвечать, как только на них поступал трафик. Отсюда и длинное восстановление с волнами частичного улучшения. К утру пятницы Microsoft фиксировала более широкое восстановление в Северной Америке, устойчивые улучшения в большей части Европы и обнадёживающие сигналы в Азиатско-Тихоокеанском регионе. При этом компания предупреждала об остаточных проблемах с доступом и задержках почты, пока устраняет очереди и проверяет стабильность по разным способам подключения.
Точное число пострадавших Microsoft не назвала. Для оценки потенциального радиуса достаточно другого ориентира: в январе компания сообщала, что количество платных коммерческих подписок Microsoft 365 превысило 450 млн. Это не равно числу пользователей, затронутых именно этим эпизодом, но хорошо показывает, почему отказ одной платформы становится проблемой не только для ИТ-служб, но и для учреждений, у которых нет права поставить работу на паузу.
Бывший руководитель британского Национального центра кибербезопасности Киаран Мартин назвал случившееся одним из крупнейших сбоев в истории и допустил, что по тяжести он может превзойти недавние инциденты AWS и CrowdStrike. Сравнение неизбежно, хотя характер аварий различается. В случае CrowdStrike последствия усилил неудачный апдейт на конечных устройствах. Здесь же уязвимой точкой оказалась централизованная облачная инфраструктура и её собственные механизмы контроля здоровья.
Что проверить ИТ-командам уже сейчас
Для разработчиков и ИТ-директоров глобальный сбой Microsoft — повод проверить не SLA в договоре, а реальную карту зависимостей. Если вход в корпоративные системы связан с Microsoft 365, коды MFA приходят в Outlook, документы живут в OneDrive, а поддержка общается через Teams, один инфраструктурный инцидент может выключить сразу несколько резервных контуров. Отдельно стоит проверить сценарий «почта отправляется, но не приходит»: очереди, сроки жизни сообщений, альтернативные каналы для критических уведомлений и процедуру ручной верификации пользователей.
Бизнесу полезно заранее определить процессы, которые должны работать без корпоративной почты и облачного офиса хотя бы сутки. Это не обязательно означает срочно строить второй полноценный стек: часто достаточно автономного списка контактов, альтернативного канала связи, офлайн-доступа к критическим инструкциям и заранее согласованного режима для службы поддержки, финансов и кадров. Но эти меры нужно тестировать до аварии — в день сбоя доступ к той самой инструкции нередко оказывается зависим от того же поставщика.
Microsoft пообещала выпустить полный отчёт после завершения устранения инцидента, включая первопричину и дополнительные защитные меры. Главный вопрос после него будет не в том, почему серверы не прошли health check, а в том, почему отказ этого контура смог так быстро превратиться в глобальный сбой Microsoft с последствиями для почты, банковских подтверждений, медицины и правосудия. Чем плотнее организации собирают рабочий день вокруг единой облачной экосистемы, тем важнее становится способность пережить её недоступность без героизма в чатах и таблицах.
