Microsoft postează analiza cauzei principale pentru marile probleme de conectare la Microsoft 365 din această săptămână

Săptămâna aceasta am avut o perioadă de nefuncționare de aproape 5 ore pentru Microsoft 365, cu utilizatorii care nu se pot conecta la mai multe servicii, inclusiv OneDrive și Microsoft Teams.

Astăzi Microsoft a publicat o analiză a cauzei principale a problemei, despre care Microsoft spune că s-a datorat actualizării serviciului care trebuia să vizeze un inel de testare de validare intern, dar care a fost implementat direct în mediul de producție Microsoft din cauza unui defect de cod latent în sistemul de proces de implementare sigur (SDP) al serviciului de backend Azure AD.

Microsoft spune că între aproximativ 21:25 UTC pe 28 septembrie 2020 și 00:23 UTC pe 29 septembrie 2020, clienții au întâmpinat erori la efectuarea operațiunilor de autentificare pentru toate aplicațiile și serviciile Microsoft și terțe care depind de Azure Active Directory (Azure AD) ) pentru autentificare. Problema a fost complet atenuată pentru toți până la 2:25 a doua zi.

SUA și Australia au fost cele mai afectate, doar 17% dintre utilizatorii din SUA s-au putut conecta cu succes.

Problema a fost agravată de faptul că Microsoft nu a putut derula actualizarea din cauza defectului latent al sistemului SDP care corupe metadatele de implementare, ceea ce înseamnă că actualizarea a trebuit să fie anulată manual.

Microsoft și-a cerut scuze clienților afectați și a spus că continuă să ia măsuri pentru a îmbunătăți Platforma Microsoft Azure și procesele acestora pentru a se asigura că astfel de incidente nu vor avea loc în viitor. Unul dintre pașii planificați include aplicarea de protecție suplimentară pentru sistemul SDP de backend al serviciului Azure AD pentru a preveni clasa de probleme identificate.

Citiți mai jos analiza completă:

RCA – Erori de autentificare în mai multe servicii Microsoft și aplicații integrate Azure Active Directory (ID de urmărire SM79-F88)

Rezumatul impactului: Între aproximativ 21:25 UTC pe 28 septembrie 2020 și 00:23 UTC pe 29 septembrie 2020, este posibil ca clienții să fi întâmpinat erori la efectuarea operațiunilor de autentificare pentru toate aplicațiile și serviciile Microsoft și terță parte care depind de Azure Active Directory (Azure AD) pentru autentificare. Au fost afectate și aplicațiile care utilizează Azure AD B2C pentru autentificare.

Utilizatorii care nu erau deja autentificați la serviciile cloud folosind Azure AD au avut mai multe șanse să întâmpine probleme și este posibil să fi văzut mai multe eșecuri ale solicitărilor de autentificare corespunzătoare numărului mediu de disponibilitate afișat mai jos. Acestea au fost agregate pentru diferiți clienți și sarcini de lucru.

• Europa: rata de succes de 81% pe durata incidentului.
• America: rata de succes de 17% pe durata incidentului, îmbunătățindu-se la 37% chiar înainte de atenuare.
• Asia: rata de succes de 72% în primele 120 de minute ale incidentului. Pe măsură ce a început traficul de vârf în timpul orelor de lucru, disponibilitatea a scăzut la 32% la cel mai scăzut nivel.
• Australia: rata de succes de 37% pe durata incidentului.

Serviciul a fost restabilit la disponibilitatea operațională normală pentru majoritatea clienților până la 00:23 UTC pe 29 septembrie 2020, cu toate acestea, am observat eșecuri rare la cererea de autentificare, care ar fi putut afecta clienții până la 02:25 UTC.

Utilizatorii care s-au autentificat înainte de momentul începerii impactului erau mai puțin probabil să întâmpine probleme în funcție de aplicațiile sau serviciile pe care le accesau.

Măsurile de reziliență în vigoare au protejat serviciile de identități gestionate pentru mașini virtuale, seturi de mașini virtuale la scară și servicii Azure Kubernetes, cu o disponibilitate medie de 99.8% pe toată durata incidentului.

Cauza de bază: Pe 28 septembrie, la 21:25 UTC, a fost implementată o actualizare a serviciului care vizează un inel de testare de validare intern, provocând o blocare la pornire în serviciile de backend Azure AD. Un defect de cod latent al serviciului de backend Azure AD Safe Deployment Process (SDP) a făcut ca acesta să fie implementat direct în mediul nostru de producție, ocolind procesul nostru normal de validare.

Azure AD este conceput pentru a fi un serviciu geo-distribuit implementat într-o configurație activ-activ cu mai multe partiții în mai multe centre de date din întreaga lume, construite cu granițe de izolare. În mod normal, modificările vizează inițial un inel de validare care nu conține date despre clienți, urmat de un inel interior care conține numai utilizatori Microsoft și, în sfârșit, mediul nostru de producție. Aceste modificări sunt implementate în faze pe cinci inele pe parcursul mai multor zile.

În acest caz, sistemul SDP nu a reușit să vizeze corect inelul de testare de validare din cauza unui defect latent care a afectat capacitatea sistemului de a interpreta metadatele de implementare. În consecință, toate inelele au fost vizate simultan. Implementarea incorectă a cauzat degradarea disponibilității serviciului.

În câteva minute de la impact, am luat măsuri pentru a anula schimbarea utilizând sisteme automate de rollback care ar fi limitat în mod normal durata și gravitatea impactului. Cu toate acestea, defectul latent al sistemului nostru SDP a corupt metadatele de implementare și a trebuit să recurgem la procese manuale de rollback. Acest lucru a prelungit semnificativ timpul de atenuare a problemei.

Atenuare: Monitorizarea noastră a detectat degradarea serviciului în câteva minute de la impactul inițial și ne-am angajat imediat pentru a iniția depanarea. Au fost întreprinse următoarele activități de atenuare:

• Impactul a început la 21:25 UTC, iar în 5 minute monitorizarea noastră a detectat o stare nesănătoasă, iar ingineria a fost imediat angajată.
• În următoarele 30 de minute, concomitent cu depanarea problemei, au fost întreprinși o serie de pași pentru a încerca să minimizeze impactul clienților și să accelereze atenuarea. Aceasta a inclus extinderea proactivă a unora dintre serviciile Azure AD pentru a gestiona încărcarea anticipată odată ce ar fi fost aplicată o atenuare și transferarea anumitor sarcini de lucru la un sistem de autentificare Azure AD de rezervă.
• La 22:02 UTC, am stabilit cauza principală, am început remedierea și am inițiat mecanismele noastre automate de retragere.
• Derularea automată a eșuat din cauza coruperii metadatelor SDP. La ora 22:47 UTC am inițiat procesul de actualizare manuală a configurației serviciului care ocolește sistemul SDP, iar întreaga operațiune a fost finalizată până la 23:59 UTC.
• Până la 00:23 UTC, suficiente instanțe de serviciu backend au revenit la o stare sănătoasă pentru a atinge parametrii operaționali normali ai serviciului.
• Toate instanțele de service cu impact rezidual au fost recuperate până la 02:25 UTC.

Paşii următori: Ne cerem scuze sincer pentru impactul asupra clienților afectați. Luăm în mod continuu măsuri pentru a îmbunătăți Platforma Microsoft Azure și procesele noastre pentru a ne asigura că astfel de incidente nu vor avea loc în viitor. În acest caz, acestea includ (dar nu se limitează la) următoarele:

Am terminat deja

• S-a remediat defectul de cod latent în sistemul SDP de backend Azure AD.
• S-a remediat sistemul de rollback existent pentru a permite restaurarea ultimelor metadate cunoscute bune pentru a proteja împotriva corupției.
• Extindeți sfera și frecvența exercițiilor de operare de derulare.

Pașii rămași includ

• Aplicați protecții suplimentare sistemului SDP de backend al serviciului Azure AD pentru a preveni clasa de probleme identificate aici.
• Accelerați lansarea sistemului de autentificare de rezervă Azure AD la toate serviciile cheie ca prioritate de top pentru a reduce semnificativ impactul unui tip similar de problemă în viitor.
• Încorporați scenarii Azure AD în conducta de comunicații automate care postează comunicarea inițială către clienții afectați în 15 minute de la impact.

Oferi feedback: Vă rugăm să ne ajutați să îmbunătățim experiența de comunicare cu clienții Azure participând la sondajul nostru: https://aka.ms/AzurePIRSurvey

de ZDNet