Firma Microsoft publikuje analizę głównych przyczyn największych problemów z logowaniem do usługi Microsoft 365, które wystąpiły w tym tygodniu

W tym tygodniu mieliśmy prawie 5-godzinny przestój dla Microsoft 365, z użytkownikami, którzy nie mogą zalogować się do wielu usług, w tym OneDrive i Microsoft Teams.

Dziś Microsoft opublikował analizę przyczyn problemu, który, jak twierdzi Microsoft, był spowodowany aktualizacją usługi, która miała być ukierunkowana na wewnętrzny pierścień testowy weryfikacyjny, ale zamiast tego została wdrożona bezpośrednio w środowisku produkcyjnym firmy Microsoft z powodu ukrytego defektu kodu w systemie procesu bezpiecznego wdrażania (SDP) usługi zaplecza usługi Azure AD.

Microsoft twierdzi, że między około 21:25 UTC 28 września 2020 r. a 00:23 UTC 29 września 2020 r. klienci napotkali błędy podczas wykonywania operacji uwierzytelniania dla wszystkich aplikacji i usług firmy Microsoft i innych firm, które są zależne od Azure Active Directory (Azure AD ) do uwierzytelniania. Problem został całkowicie złagodzony dla wszystkich dopiero o 2:25 następnego dnia.

Najbardziej ucierpiały Stany Zjednoczone i Australia, gdzie tylko 17% użytkowników w USA mogło się pomyślnie zalogować.

Problem został spotęgowany przez fakt, że firma Microsoft nie była w stanie wycofać aktualizacji z powodu ukrytej usterki systemu SDP, która uszkadza metadane wdrożenia, co oznacza, że ​​aktualizację trzeba było wycofać ręcznie.

Firma Microsoft przeprosiła klientów, których to dotyczy, i poinformowała, że ​​nadal podejmują kroki w celu ulepszenia platformy Microsoft Azure i jej procesów, aby zapewnić, że takie incydenty nie wystąpią w przyszłości. Jeden z planowanych kroków obejmuje zastosowanie dodatkowych zabezpieczeń do systemu SDP zaplecza usługi Azure AD, aby zapobiec zidentyfikowanej klasie problemów.

Przeczytaj pełną analizę poniżej:

RCA — błędy uwierzytelniania w wielu usługach firmy Microsoft i zintegrowanych aplikacjach Azure Active Directory (identyfikator śledzenia SM79-F88)

Podsumowanie wpływu: Między około 21:25 UTC 28 września 2020 r. a 00:23 UTC 29 września 2020 r. klienci mogli napotkać błędy podczas wykonywania operacji uwierzytelniania dla wszystkich aplikacji i usług firmy Microsoft i innych firm, które są zależne od Azure Active Directory (Azure AD) do uwierzytelniania. Wpłynęło to również na aplikacje korzystające z usługi Azure AD B2C do uwierzytelniania.

Użytkownicy, którzy nie zostali jeszcze uwierzytelnieni w usługach w chmurze przy użyciu usługi Azure AD, byli bardziej narażeni na problemy i mogli napotkać wiele błędów żądań uwierzytelnienia odpowiadających średnim liczbom dostępności pokazanym poniżej. Zostały one zagregowane dla różnych klientów i obciążeń.

• Europa: 81% skuteczności w czasie trwania incydentu.
• Ameryki: 17% wskaźnik sukcesu w czasie trwania incydentu, poprawiający się do 37% tuż przed złagodzeniem skutków.
• Azja: 72% skuteczności w pierwszych 120 minutach incydentu. Wraz z rozpoczęciem szczytowego ruchu w godzinach pracy dostępność spadła do 32% na najniższym poziomie.
• Australia: 37% wskaźnik sukcesu w czasie trwania incydentu.

Usługa została przywrócona do normalnej dostępności operacyjnej dla większości klientów do 00:23 UTC 29 września 2020 r., jednak zaobserwowaliśmy rzadkie błędy żądań uwierzytelnienia, które mogły mieć wpływ na klientów do 02:25 UTC.

Użytkownicy, którzy dokonali uwierzytelnienia przed czasem rozpoczęcia wpływu, rzadziej napotykali problemy w zależności od aplikacji lub usług, z których korzystali.

Odporność mierzy chronione usługi tożsamości zarządzanej dla maszyn wirtualnych, zestawów skalowania maszyn wirtualnych i usług Azure Kubernetes ze średnią dostępnością 99.8% przez cały czas trwania incydentu.

Główna przyczyna: W dniu 28 września o godzinie 21:25 czasu UTC wdrożono aktualizację usługi skierowaną do wewnętrznego pierścienia testu weryfikacyjnego, powodując awarię podczas uruchamiania w usługach zaplecza usługi Azure AD. Ukryta wada kodu w systemie procesu bezpiecznego wdrażania (SDP) usługi zaplecza usługi Azure AD spowodowała wdrożenie tego bezpośrednio w naszym środowisku produkcyjnym, z pominięciem naszego normalnego procesu weryfikacji.

Usługa Azure AD została zaprojektowana jako usługa rozproszona geograficznie wdrożona w konfiguracji aktywny-aktywny z wieloma partycjami w wielu centrach danych na całym świecie, zbudowana z granicami izolacji. Zwykle zmiany początkowo dotyczą pierścienia sprawdzania poprawności, który nie zawiera danych klientów, a następnie wewnętrznego pierścienia zawierającego tylko użytkowników firmy Microsoft, a na końcu naszego środowiska produkcyjnego. Te zmiany są wdrażane etapami na pięciu pierścieniach w ciągu kilku dni.

W tym przypadku system SDP nie mógł poprawnie skierować pierścienia testów weryfikacyjnych z powodu ukrytej defektu, który wpłynął na zdolność systemu do interpretacji metadanych wdrożenia. W związku z tym wszystkie pierścienie były atakowane jednocześnie. Nieprawidłowe wdrożenie spowodowało pogorszenie dostępności usługi.

W ciągu kilku minut od wpływu podjęliśmy kroki, aby cofnąć zmianę, korzystając z automatycznych systemów cofania zmian, które normalnie ograniczałyby czas trwania i dotkliwość wpływu. Jednak ukryta wada w naszym systemie SDP uszkodziła metadane wdrożenia i musieliśmy uciekać się do ręcznych procesów przywracania. To znacznie wydłużyło czas na złagodzenie problemu.

Łagodzenie: Nasze monitorowanie wykryło pogorszenie jakości usług w ciągu kilku minut od początkowego wpływu i natychmiast rozpoczęliśmy rozwiązywanie problemów. Podjęto następujące działania łagodzące:

• Uderzenie rozpoczęło się o 21:25 UTC i w ciągu 5 minut nasze monitorowanie wykryło zły stan i natychmiast zaangażowano inżynierię.
• W ciągu następnych 30 minut, jednocześnie z rozwiązywaniem problemu, podjęto szereg kroków w celu zminimalizowania wpływu klienta i przyspieszenia jego łagodzenia. Obejmowało to proaktywne skalowanie niektórych usług usługi Azure AD w celu obsługi przewidywanego obciążenia po zastosowaniu środków łagodzących i awaryjne przełączenie niektórych obciążeń do zapasowego systemu uwierzytelniania usługi Azure AD.
• O 22:02 UTC ustaliliśmy podstawową przyczynę, rozpoczęliśmy naprawę i uruchomiliśmy nasze zautomatyzowane mechanizmy wycofywania.
• Automatyczne wycofanie nie powiodło się z powodu uszkodzenia metadanych SDP. O 22:47 UTC zainicjowaliśmy proces ręcznej aktualizacji konfiguracji usługi z pominięciem systemu SDP, a cała operacja została zakończona do 23:59 UTC.
• Do 00:23 UTC wystarczająca liczba instancji usługi backendu powróciła do prawidłowego stanu, aby osiągnąć normalne parametry operacyjne usługi.
• Wszystkie instancje serwisowe z szczątkowym wpływem zostały przywrócone do 02:25 UTC.

Kolejne etapy: Serdecznie przepraszamy za wpływ na klientów, których to dotyczy. Nieustannie podejmujemy kroki w celu ulepszenia platformy Microsoft Azure i naszych procesów, aby zapewnić, że takie incydenty nie wystąpią w przyszłości. W tym przypadku obejmuje to (ale nie ogranicza się do) następujące:

Już zakończyliśmy

• Naprawiono ukryty defekt kodu w systemie SDP zaplecza usługi Azure AD.
• Naprawiono istniejący system wycofywania, aby umożliwić przywracanie ostatnich znanych dobrych metadanych w celu ochrony przed uszkodzeniem.
• Rozszerz zakres i częstotliwość ćwiczeń operacji wycofywania.

Pozostałe kroki obejmują

• Zastosuj dodatkowe zabezpieczenia do systemu SDP zaplecza usługi Azure AD, aby zapobiec zidentyfikowanej tutaj klasie problemów.
• Przyspiesz wdrażanie systemu uwierzytelniania kopii zapasowych usługi Azure AD we wszystkich kluczowych usługach jako najwyższy priorytet, aby znacznie zmniejszyć wpływ podobnych problemów w przyszłości.
• Dołącz scenariusze usługi Azure AD do zautomatyzowanego potoku komunikacyjnego, który publikuje początkową komunikację do dotkniętych klientów w ciągu 15 minut od wpływu.

Przekazać opinię: Pomóż nam ulepszyć komunikację z klientami platformy Azure, wypełniając naszą ankietę: https://aka.ms/AzurePIRSurvey

przez ZDNet