Сбой Microsoft 365, начавшийся 12 ноября в 18:26 GMT, затронул Exchange Online, Teams, Copilot и ряд функций офисного пакета. Для компаний это был не просто неудобный вечер без почты: когда один поставщик одновременно держит коммуникации, документы и совместную работу, техническая авария быстро превращается в остановку процессов. Особенно знакомый сценарий для русскоязычных IT-команд, которые строят рабочее место вокруг одного облачного стека.
Microsoft назвала инцидент «деградацией сервиса». По данным The Register, у пользователей не работал Exchange Online, возникали проблемы с просмотром недавно открытых файлов в приложении Microsoft 365, нестабильно работал Copilot, пострадали сервисы Microsoft 365 Education. К 14:01 GMT 13 ноября компания сообщила об улучшении доступности, однако для организаций, у которых за это время сорвались переписка с клиентами, согласования и внутренние встречи, формулировка о постепенном восстановлении вряд ли звучала утешительно.
Главная неприятность таких инцидентов не в том, что у крупного облачного провайдера случается ошибка. Ошибаются все — от небольшой команды, обслуживающей корпоративный Git-сервер, до гиперскейлера. Проблема появляется, когда отказ одного контура выключает сразу несколько независимых на бумаге бизнес-функций. Почта недоступна, Teams не помогает собрать аварийный созвон, документы лежат в том же облаке, а резервный канал уведомлений оказывается завязан на корпоративные учётные записи.
Этот сбой Microsoft 365 хорошо показывает разницу между резервной копией и работоспособным планом непрерывности бизнеса. Бэкап почтового ящика полезен, но не заменяет возможность принять письмо, отправить сообщение клиенту или быстро найти нужный договор. Дублирующий канал в мессенджере тоже не спасает, если сотрудники не знают, где лежат контакты, как включается доступ и кто имеет право публиковать внешние уведомления. План, который ни разу не проверяли в условиях недоступности основного поставщика, обычно обнаруживается в самый неподходящий момент.
Конкуренты Microsoft ожидаемо использовали аварию как повод напомнить о рисках концентрации. Сооснователь Nextcloud Йос Поортвлит выразил сочувствие администраторам, но подчеркнул: организации слишком сильно зависят от одной экосистемы. По его словам, в критической инфраструктуре такая зависимость мешает быстро сменить провайдера, включить резервную площадку или продолжить работу в изолированном контуре. CEO облачного провайдера Civo Марк Буст сформулировал ту же мысль жёстче: тревожит не сам факт сбоя у Microsoft, а концентрация критически важной инфраструктуры у немногих компаний.
Для IT-директора здесь нет простого рецепта в духе «срочно уходите из облака». Собственная инфраструктура тоже ломается, требует людей, обновлений, мониторинга и денег. Мультиоблачная архитектура может добавить устойчивости, но способна столь же успешно добавить сложность, дублирование данных и новый класс ошибок в интеграциях. Вопрос практичнее: какие процессы действительно нельзя останавливать на несколько часов и можно ли выполнить их при недоступности Microsoft 365? Ответы стоит искать не в презентации вендора, а в сценариях отказа.
Полезный минимум для команд — составить карту зависимостей: где хранятся документы, какой сервис отвечает за идентификацию, чем сотрудники получают аварийные инструкции, как общаются с заказчиками и где находятся контакты вне корпоративного каталога. Затем нужны проверяемые процедуры: резервные адреса для ключевых ролей, независимый канал оповещения, экспорт критичных данных и понятный порядок действий для службы поддержки. Это не обязательно означает второй полноценный офисный пакет для всех сотрудников; иногда достаточно продуманного режима деградации для финансов, продаж, разработки и руководителей инцидента.
Инцидент пришёлся на момент, когда Microsoft сама призывает клиентов считать неподдерживаемые Exchange Server 2016 и 2019 постоянно уязвимыми. Переезд в Exchange Online логично снижает часть эксплуатационных и безопасностных рисков, но меняет их характер: вместо проблем с собственным сервером компания принимает риск недоступности внешней платформы. Это нормальный компромисс, если он осознан, зафиксирован в требованиях к доступности и подкреплён планом на случай отказа.
Сбой Microsoft 365 не доказывает, что единый поставщик всегда плох, а несколько поставщиков автоматически делают компанию устойчивой. Он задаёт более неудобный вопрос: сколько часов бизнес реально может прожить без почты, чатов и документов — и проверял ли это кто-то до аварии? В этой истории особенно ценны не громкие обещания «отказоустойчивости», а измеримые ответы и отрепетированные действия. Детали инцидента и комментарии участников собрал .