Корпорація Майкрософт публікує аналіз першопричин великих проблем із входом у Microsoft 365 цього тижня

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

ТЕПЕР Microsoft опублікувала аналіз першопричини проблеми, яке, за словами Microsoft, було пов’язане з оновленням служби, яке мало націлитися на внутрішнє тестове кільце перевірки, але натомість було розгорнуто безпосередньо у виробничому середовищі Microsoft через прихований дефект коду в системі безпечного розгортання (SDP) серверної служби Azure AD.

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

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

Проблема ускладнювалася тим, що корпорація Майкрософт не могла відкотити оновлення через прихований дефект у їхній системі SDP, що пошкоджує метадані розгортання, тобто оновлення потрібно було відкотити вручну.

Корпорація Майкрософт вибачилася перед постраждалими клієнтами та заявила, що продовжує вживати заходів для вдосконалення платформи 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 UTC було розгорнуто оновлення служби, націлене на внутрішнє тестове кільце перевірки, що спричинило збій під час запуску у внутрішніх службах 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 UTC достатньо екземплярів серверної служби повернулися до працездатного стану, щоб досягти нормальних робочих параметрів служби.
• Усі службові екземпляри із залишковим впливом були відновлені до 02:25 UTC.

Наступні кроки: Ми щиро перепрошуємо за наслідки для постраждалих клієнтів. Ми постійно вживаємо заходів для вдосконалення платформи Microsoft Azure і наших процесів, щоб уникнути подібних інцидентів у майбутньому. У цьому випадку це включає (але не обмежується) наступне:

Ми вже завершили

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

Решта кроків включає

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

Забезпечити зворотній звязок: Допоможіть нам покращити взаємодію з клієнтами Azure, пройшовши опитування: https://aka.ms/AzurePIRSurvey

через ZDNet