Сбой в работе Microsoft 31 августа: риск зависимости от одного поставщика

Когда основная облачная инфраструктура выходит из строя, работа современных предприятий полностью останавливается. В понедельник, 31 августа, тысячи организаций по всему миру на собственном опыте убедились в своей зависимости от цифровых технологий, когда сервис Microsoft Outlook и более широкая экосистема Microsoft 365 столкнулись с многочасовым сбоем в работе.

Руководители, отвечающие за обеспечение непрерывности бизнеса, хорошо знакомы с таким сценарием риска: полная зависимость от одного поставщика в отношении ключевых операционных инструментов делает организацию уязвимой перед рисками, связанными с наличием единственной точки отказа.

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

Сбои начались ранним утром в понедельник, что привело к резкому росту числа сообщений о сбоях на таких платформах телеметрии, как Downdetector. То, что поначалу казалось обычной проблемой с подключением клиентов, быстро переросло в масштабное инфраструктурное происшествие.

• Основные симптомы, связанные с воздействием: Пользователи всех затронутых арендаторов не могли запустить настольное приложение Outlook или открыть веб-портал. Организации сообщали о серьезных заторах в почтовом потоке, полных сбоях при отправке или получении сообщений, ошибках входа в систему и аутентификации, а также о сбоях в работе функций поиска по почтовым ящикам.

• Каскадное развертывание в пакете Microsoft 365: Хотя Outlook и Exchange Online стали наиболее заметными точками сбоя, компания Microsoft признала в отчетах об инцидентах MO1465074 / EX1464935, что основная проблема привела к ухудшению работы сопутствующих бизнес-инструментов. Последствия инцидента затронули Microsoft Teams, OneDrive for Business, SharePoint Online, Microsoft Purview и Microsoft Defender XDR.

• Глобальный охват и неравномерное воздействие: Инцидент стал достоянием общественности около 17:30 по UTC и охватил обширную территорию. В Америке о серьезных сбоях сообщалось в нескольких штатах США (включая Техас, Нью-Йорк, Кентукки и Неваду), а также поступали сообщения из стран Латинской Америки. На тихоокеанском побережье последствия стали ощущаться в начале рабочего дня (какое начало понедельника!). Европейские предприятия столкнулись с серьезными ошибками аутентификации и сбоями в доставке сообщений в конце рабочего дня, что нарушило критически важные процедуры закрытия месяца 31 августа. Последствия были неодинаковыми: в то время как одни сотрудники сохранили доступ, их коллеги, работающие в том же самом тенанте, оказались полностью заблокированными.

• Продолжительность более 10 часов: Инцидент длился почти 11 часов, пока показатели телеметрии не стабилизировались. Из-за длительности инцидента ИТ-команды с трудом поддерживали базовую связь как внутри компании, так и с клиентами.

• Основная причина и меры по устранению: Компания Microsoft установила, что причиной сбоя стала неверная настройка ключевого компонента аутентификации и уровня подключения протокола, используемого внутренними сервисами Exchange Online. В ответ на это инженеры развернули целевой патч для сброса настроек аутентификации, постепенно внедряя обновления по всей серверной инфраструктуре.

Когда происходит инцидент, подобный MO1465074 / EX1464935, основная электронная почта, внутренний чат, хранилище файлов и панели мониторинга безопасности могут одновременно перестать работать. В таких ситуациях традиционные планы восстановления после сбоев, основанные на использовании резервных инструментов в рамках то же самое Сбой облачной экосистемы.

Если в качестве резервного плана связи вы используете Microsoft Teams, но Teams опирается на ту же базовую инфраструктуру идентификации и аутентификации, что и Exchange Online, то в случае сбоя основной системы сбой произойдет и в резервной системе. Настоящая отказоустойчивость требует структурного разнообразия поставщиков.