Сбой Microsoft 365, начавшийся 12 ноября 2026 года, нарушил работу банков, бирж, авиакомпаний и логистических операторов в США, Европе и Азиатско-Тихоокеанском регионе. Там, где обработка сделки обычно занимает секунды, сотрудникам пришлось звонить контрагентам, писать в мессенджеры и подтверждать операции факсом — хороший повод ещё раз проверить, насколько бизнес готов к недоступности привычного облака.
Проблемы затронули Outlook, Teams, Copilot и другие сервисы Microsoft 365. Как сообщает vc.ru, Microsoft частично восстановила работу платформы, но на момент публикации не устранила неполадки полностью. Компания заявила, что инцидент не связан с кибератакой: причиной стала повышенная нагрузка на инфраструктуру в отдельных регионах.
Особенно болезненным оказался сбой Microsoft 365 для финансового сектора. Перебои с электронной почтой фиксировали Barclays, Deutsche Bank, ING, Nasdaq и Euronext. Банки в Сингапуре и на Тайване не могли завершить часть сделок, а японские финансовые организации использовали факс для подтверждения торговых операций. Это не ретрофутуризм ради красивого заголовка: в сделках важны скорость, журнал коммуникаций и формальное подтверждение условий, а корпоративная почта часто встроена в этот процесс глубже, чем кажется со стороны.
По данным собеседников Bloomberg, наибольшие сложности возникли при обработке и подтверждении операций. Если Outlook недоступен, одна сторона сделки не может быстро отправить или получить инструкции, подтверждения и сопроводительные документы. Телефон помогает договориться, но не заменяет привычную автоматизированную цепочку. Мессенджеры ускоряют коммуникацию, однако не всегда соответствуют внутренним правилам хранения переписки и контроля рисков.
Для рынка это означает не только раздражение сотрудников. Когда подтверждение сделки становится ручным, участники осторожнее работают с контрагентами и могут сократить активность. Bloomberg отмечает риск для ликвидности: финансовые организации менее охотно совершают операции без автоматизированных систем обработки. Даже короткий инфраструктурный сбой способен превратить технологическую проблему в операционную — с задержками, дополнительными проверками и ростом вероятности ошибок.
От отчётности до бронирований
Последствия вышли далеко за пределы трейдинговых залов. Швейцарская Richemont, которой принадлежит Cartier, отложила публикацию финансовой отчётности. Американский производитель электрогрузовиков Workhorse поступил так же. Для публичной компании задержка отчёта — не просто неудобство в календаре: инвесторы, аналитики и регуляторы ожидают информацию в определённые сроки, а объяснять перенос приходится публично.
Индийские авиакомпании IndiGo, Akasa Air и Air India предупредили пассажиров о проблемах в работе служб поддержки. В Японии логистическая Sagawa Express прекратила обработку онлайн-бронирований, а фармацевтическая Taisho начала принимать заказы по телефону. С проблемами также столкнулась Maersk. В Великобритании технические сбои затронули лондонскую полицию, Национальную службу здравоохранения, железнодорожного оператора National Rail и страховую Aviva.
Общий паттерн здесь важнее списка пострадавших. Почта и средства совместной работы давно перестали быть второстепенным офисным набором. Через них проходят согласования, заявки, поддержка клиентов, подтверждения поставок, доступ к документам и внутренние уведомления. Когда сервис исчезает на несколько часов или дольше, резервный сценарий часто оказывается не автоматическим переключением на другую платформу, а набором разрозненных ручных процедур.
Для российских разработчиков и IT-руководителей этот инцидент — практическая проверка архитектурных убеждений. Наличие резервных копий документов само по себе не спасает, если недоступны корпоративные идентификаторы, почтовые адреса, календари, чаты и правила маршрутизации обращений. План непрерывности должен отвечать на более неприятные вопросы: кто уполномочен подтверждать операции по альтернативному каналу, где хранится актуальный список контактов, как фиксируются договорённости и как команда узнаёт о массовой недоступности основной платформы.
Полезно отдельно тестировать не только отказ собственных серверов, но и сбой SaaS-поставщика. У многих компаний облачный сервис воспринимается как внешняя константа: его не нужно администрировать, значит, о нём можно не думать. Но перенос рисков эксплуатации поставщику не отменяет риски зависимости от него. Чем больше процессов завязано на одного вендора, тем важнее заранее определить допустимое время простоя и рабочие альтернативы для критичных функций.
Сбой Microsoft 365 показал, что цифровая устойчивость измеряется не числом облачных подписок, а способностью продолжать работу при их недоступности. После восстановления сервисов компаниям останется ответить на менее заметный, но более полезный вопрос: какие процессы действительно нуждаются в единой платформе, а какие уже давно требуют независимого резервного контура.