Microsoft публикует анализ первопричин крупных проблем со входом в Microsoft 365 на этой неделе

На этой неделе у нас было почти 5-часовое время простоя для Microsoft 365, с пользователями, которые не могут войти в несколько служб, включая OneDrive и Microsoft Teams.

Cегодня Microsoft опубликовала анализ основных причин проблемы., которое, по словам Microsoft, было связано с обновлением службы, которое должно было быть нацелено на внутреннее тестовое кольцо проверки, но вместо этого было развернуто непосредственно в производственной среде Microsoft из-за скрытого дефекта кода в системе процесса безопасного развертывания (SDP) серверной службы Azure AD.

Microsoft сообщает, что примерно между 21:25 UTC 28 сентября 2020 г. и 00:23 UTC 29 сентября 2020 г. клиенты столкнулись с ошибками при выполнении операций аутентификации для всех приложений и служб Microsoft и сторонних разработчиков, зависящих от Azure Active Directory (Azure AD). ) для аутентификации. Проблема была полностью устранена только к 2:25 следующего дня.

Больше всего пострадали США и Австралия: только 17% пользователей в США смогли успешно войти в систему.

Проблема усугублялась тем, что Microsoft не могла откатить обновление из-за скрытого дефекта в их системе SDP, который повреждал метаданные развертывания, а это означало, что обновление пришлось откатывать вручную.

Microsoft принесла извинения пострадавшим клиентам и заявила, что продолжает предпринимать шаги по улучшению платформы Microsoft Azure и своих процессов, чтобы предотвратить повторение подобных инцидентов в будущем. Один из запланированных шагов включает в себя применение дополнительных средств защиты к серверной системе SDP службы Azure AD для предотвращения выявленных проблем.

Читайте полный анализ ниже:

RCA — ошибки аутентификации в нескольких службах Microsoft и интегрированных приложениях Azure Active Directory (идентификатор отслеживания SM79-F88)

Резюме воздействия: Приблизительно между 21:25 UTC 28 сентября 2020 г. и 00:23 UTC 29 сентября 2020 г. клиенты могли столкнуться с ошибками при выполнении операций проверки подлинности для всех приложений и служб Microsoft и сторонних производителей, зависящих от Azure Active Directory (Azure AD). для аутентификации. Также были затронуты приложения, использующие Azure AD B2C для проверки подлинности.

Пользователи, которые еще не прошли проверку подлинности в облачных службах с помощью Azure AD, с большей вероятностью столкнутся с проблемами и могут столкнуться с несколькими ошибками запросов проверки подлинности, соответствующими средним значениям доступности, показанным ниже. Они были объединены для различных клиентов и рабочих нагрузок.

• Европа: 81% успеха на протяжении всего инцидента.
• Северная и Южная Америка: 17 % успеха на протяжении всего инцидента, повышение до 37 % непосредственно перед устранением последствий.
• Азия: 72% успеха в первые 120 минут инцидента. Когда начался пик трафика в рабочие часы, доступность упала до 32% в самом низком уровне.
• Австралия: 37% успеха на протяжении всего инцидента.

Сервис был восстановлен до нормальной операционной доступности для большинства клиентов к 00:23 UTC 29 сентября 2020 г., однако мы наблюдали нечастые сбои запросов аутентификации, которые могли повлиять на клиентов до 02:25 UTC.

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

Измерения устойчивости на месте защищенных служб управляемых удостоверений для виртуальных машин, масштабируемых наборов виртуальных машин и служб Azure Kubernetes со средней доступностью 99.8 % на протяжении всего инцидента.

Первопричина: 28 сентября в 21:25 по всемирному координированному времени было развернуто обновление службы, предназначенное для внутреннего тестового кольца проверки, что привело к сбою при запуске в серверных службах Azure AD. Скрытый дефект кода в системе процесса безопасного развертывания (SDP) серверной службы Azure AD привел к тому, что он был развернут непосредственно в нашей производственной среде, минуя наш обычный процесс проверки.

Azure AD разработан как геораспределенная служба, развернутая в конфигурации «активный-активный» с несколькими разделами в нескольких центрах обработки данных по всему миру, построенная с границами изоляции. Обычно изменения первоначально нацелены на кольцо проверки, которое не содержит данных о клиентах, затем следует внутреннее кольцо, содержащее только пользователей Microsoft, и, наконец, наша производственная среда. Эти изменения развертываются поэтапно в пяти кольцах в течение нескольких дней.

В этом случае системе SDP не удалось правильно нацелить проверочное тестовое кольцо из-за скрытого дефекта, который повлиял на способность системы интерпретировать метаданные развертывания. Следовательно, все кольца были нацелены одновременно. Неправильное развертывание привело к снижению доступности службы.

В течение нескольких минут после воздействия мы предприняли шаги, чтобы отменить изменение, используя автоматизированные системы отката, которые обычно ограничивали бы продолжительность и серьезность воздействия. Однако скрытый дефект в нашей системе SDP повредил метаданные развертывания, и нам пришлось прибегнуть к ручному процессу отката. Это значительно увеличило время устранения проблемы.

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

• Столкновение началось в 21:25 UTC, и в течение 5 минут наш мониторинг зафиксировал нездоровое состояние, и инженеры были немедленно задействованы.
• В течение следующих 30 минут одновременно с устранением неполадок был предпринят ряд шагов, направленных на минимизацию воздействия на клиентов и ускорение устранения последствий. Это включало упреждающее масштабирование некоторых служб Azure AD для обработки ожидаемой нагрузки после применения мер по снижению риска и перенос определенных рабочих нагрузок на резервную систему проверки подлинности Azure AD.
• В 22:02 UTC мы установили первопричину, начали устранение и запустили наши автоматические механизмы отката.
• Не удалось выполнить автоматический откат из-за повреждения метаданных SDP. В 22:47 UTC мы инициировали процесс ручного обновления конфигурации службы в обход системы SDP, и вся операция была завершена к 23:59 UTC.
• К 00:23 по всемирному координированному времени в работоспособное состояние вернулось достаточно экземпляров серверной службы, чтобы достичь нормальных рабочих параметров службы.
• Все экземпляры службы с остаточным воздействием были восстановлены к 02:25 UTC.

Следующие шаги: Мы искренне извиняемся за влияние на пострадавших клиентов. Мы постоянно предпринимаем шаги по улучшению платформы Microsoft Azure и наших процессов, чтобы предотвратить подобные инциденты в будущем. В этом случае это включает (но не ограничивается) следующее:

мы уже завершили

• Исправлен скрытый дефект кода в серверной системе SDP Azure AD.
• Исправлена ​​существующая система отката, позволяющая восстанавливать последние известные исправные метаданные для защиты от повреждения.
• Увеличьте объем и частоту учений по операциям отката.

Остальные шаги включают

• Примените дополнительные средства защиты к серверной системе SDP службы Azure AD, чтобы предотвратить описанный здесь класс проблем.
• Ускорьте развертывание резервной системы проверки подлинности Azure AD для всех ключевых служб в качестве главного приоритета, чтобы значительно снизить влияние подобных проблем в будущем.
• Внедрите сценарии Azure AD в автоматизированный конвейер связи, который отправляет первоначальное сообщение затронутым клиентам в течение 15 минут после воздействия.

Обеспечить обратную связь: Пожалуйста, помогите нам улучшить взаимодействие с клиентами Azure, приняв участие в нашем опросе: https://aka.ms/AzurePIRSurvey

с помощью ZDNet