Microsoft julkaisee syyanalyysin tämän viikon suurista Microsoft 365 -kirjautumisongelmista

Tällä viikolla Microsoft 5:ssä oli lähes 365 tunnin seisokki, käyttäjät eivät pysty kirjautumaan useisiin palveluihin, mukaan lukien OneDrive ja Microsoft Teams.

Tänään Microsoft julkaisi ongelman perussyyanalyysin, joka Microsoftin mukaan johtui palvelupäivityksestä, jonka oli tarkoitus kohdistaa sisäiseen validointitestirenkaaseen, mutta joka sen sijaan otettiin käyttöön suoraan Microsoftin tuotantoympäristössä Azure AD -taustapalvelun Safe Deployment Process (SDP) -järjestelmän piilevän koodivian vuoksi.

Microsoft kertoo, että noin kello 21 UTC 25 ja 28 UTC 2020, asiakkaat kohtasivat virheitä suorittaessaan todennustoimintoja kaikille Microsoftin ja kolmannen osapuolen sovelluksille ja palveluille, jotka riippuvat Azure Active Directorystä (Azure AD). ) todennusta varten. Ongelma ratkesi täysin vasta seuraavana päivänä klo 00 mennessä.

Eniten kärsivät Yhdysvallat ja Australia, ja vain 17 % yhdysvaltalaisista käyttäjistä onnistui kirjautumaan sisään.

Ongelmaa pahensi se, että Microsoft ei pystynyt peruuttamaan päivitystä, koska heidän SDP-järjestelmänsä piilevä vika vioitti käyttöönoton metatiedot, mikä tarkoittaa, että päivitys oli peruutettava manuaalisesti.

Microsoft pahoitteli asiakkaita, joita asia koskee, ja sanoi, että he jatkavat toimenpiteitä parantaakseen Microsoft Azure Platformia ja prosessejaan varmistaakseen, ettei tällaisia ​​tapauksia tapahdu tulevaisuudessa. Yksi suunnitelluista vaiheista sisältää lisäsuojausten soveltamisen Azure AD -palvelun taustajärjestelmän SDP-järjestelmään tunnistettujen ongelmien estämiseksi.

Lue koko analyysi alta:

RCA – Todennusvirheet useissa Microsoft-palveluissa ja Azure Active Directoryn integroiduissa sovelluksissa (seurantatunnus SM79-F88)

Yhteenveto vaikutuksista: Noin 21 klo 25 UTC ja 28 klo 2020 UTC välillä asiakkaat ovat saattaneet kohdata virheitä suorittaessaan todennustoimintoja kaikille Microsoftin ja kolmannen osapuolen sovelluksille ja palveluille, jotka riippuvat Azure Active Directorystä (Azure AD). todennusta varten. Vaikutus vaikutti myös sovelluksiin, jotka käyttävät Azure AD B00C:tä todennukseen.

Käyttäjillä, joita ei vielä ollut todennettu pilvipalveluihin Azure AD:n avulla, oli todennäköisemmin ongelmia, ja he ovat saattaneet nähdä useita todennuspyyntöjen epäonnistumisia, jotka vastaavat alla esitettyjä keskimääräisiä saatavuuslukuja. Nämä on koottu eri asiakkaiden ja työkuormien mukaan.

• Eurooppa: 81 % onnistumisprosentti tapauksen keston aikana.
• Amerikka: 17 %:n onnistumisprosentti tapahtuman aikana, parani 37 %:iin juuri ennen lieventämistä.
• Aasia: 72 % onnistumisprosentti tapahtuman ensimmäisten 120 minuutin aikana. Työtuntien ruuhkahuippujen alkaessa saatavuus putosi alimmalle tasolle 32 %.
• Australia: 37 % onnistumisprosentti tapahtuman aikana.

Palvelu palautettiin normaaliksi käytettäviksi suurimmalle osalle asiakkaista 00 klo 23 UTC mennessä, mutta havaitsimme harvoin todennuspyyntöjen epäonnistumisia, jotka ovat saattaneet vaikuttaa asiakkaisiin klo 29 UTC asti.

Käyttäjät, jotka olivat todentaneet ennen vaikutuksen alkamisaikaa, eivät todennäköisesti kokeneet ongelmia riippuen sovelluksista tai palveluista, joita he käyttivät.

Käytössä olevat joustavuustoimenpiteet suojasivat Managed Identities -palveluita virtuaalikoneita, virtuaalikoneen mittakaavajoukkoja ja Azure Kubernetes -palveluita varten, joiden keskimääräinen saatavuus on 99.8 % koko tapahtuman ajan.

Pohjimmainen syy: Syyskuun 28. päivänä klo 21 UTC otettiin käyttöön sisäiseen validointitestirenkaaseen kohdistettu palvelupäivitys, joka aiheutti kaatumisen käynnistettäessä Azure AD -taustapalveluissa. Piilevä koodivika Azure AD -taustapalvelun Safe Deployment Process (SDP) -järjestelmässä sai tämän ottamaan tämän käyttöön suoraan tuotantoympäristöömme ohittaen normaalin vahvistusprosessimme.

Azure AD on suunniteltu maantieteellisesti hajautetuksi palveluksi, joka otetaan käyttöön aktiivisessa-aktiivisessa kokoonpanossa, jossa on useita osioita useissa palvelinkeskuksissa ympäri maailmaa ja joka on rakennettu eristysrajoilla. Normaalisti muutokset kohdistuvat aluksi vahvistusrenkaaseen, joka ei sisällä asiakastietoja, ja sen jälkeen sisärenkaaseen, joka sisältää vain Microsoftin käyttäjiä, ja lopuksi tuotantoympäristöömme. Nämä muutokset otetaan käyttöön vaiheittain viiden renkaan aikana useiden päivien aikana.

Tässä tapauksessa SDP-järjestelmä ei kohdistanut oikein validointitestirenkaaseen piilevän vian vuoksi, joka vaikutti järjestelmän kykyyn tulkita käyttöönoton metatietoja. Näin ollen kaikki renkaat kohdistettiin samanaikaisesti. Virheellinen käyttöönotto aiheutti palvelun saatavuuden heikkenemisen.

Muutaman minuutin kuluessa vaikutuksesta ryhdyimme toimenpiteisiin peruuttaaksemme muutoksen käyttämällä automaattisia palautusjärjestelmiä, jotka normaalisti olisivat rajoittaneet vaikutuksen kestoa ja vakavuutta. SDP-järjestelmämme piilevä vika oli kuitenkin korruptoinut käyttöönoton metatiedot, ja jouduimme turvautumaan manuaalisiin palautusprosesseihin. Tämä pidensi merkittävästi aikaa ongelman lieventämiseen.

lieventäminen: Valvontamme havaitsi palvelun heikkenemisen muutamassa minuutissa alkuperäisen vaikutuksen jälkeen, ja aloitimme vianmäärityksen välittömästi. Seuraavia lievennystoimenpiteitä toteutettiin:

• Törmäys alkoi kello 21 UTC, ja 25 minuutin kuluessa valvontamme havaitsi epäterveellisen tilan ja suunnittelu aloitettiin välittömästi.
• Seuraavien 30 minuutin aikana samaan aikaan ongelman vianmäärityksen kanssa suoritettiin useita toimenpiteitä, joilla pyrittiin minimoimaan asiakkaiden vaikutus ja nopeuttamaan lieventämistä. Tähän sisältyi joidenkin Azure AD -palveluiden ennakoiva skaalaaminen ennakoitua kuormitusta varten, kun lievennys olisi ollut käytössä, ja tiettyjen työkuormien siirtäminen Azure AD -varatodennusjärjestelmään.
• Klo 22 UTC selvitimme perimmäisen syyn, aloitimme korjaamisen ja käynnistimme automaattiset palautusmekanismimme.
• Automaattinen palautus epäonnistui SDP:n metatietojen vioittumisen vuoksi. Klo 22 UTC aloitimme SDP-järjestelmän ohittavan palvelun konfiguraation manuaalisen päivityksen, ja koko toiminto valmistui klo 47 UTC mennessä.
• Klo 00 UTC mennessä tarpeeksi taustapalveluesiintymiä palasi normaaliin tilaan saavuttaakseen normaalit palvelun toimintaparametrit.
• Kaikki huoltoesiintymät, joilla oli jäännösvaikutus, palautettiin klo 02 UTC mennessä.

Seuraavat vaiheet: Pahoittelemme vilpittömästi vaikutusta asiakkaille, joita asia koskee. Pyrimme jatkuvasti parantamaan Microsoft Azure Platformia ja prosessejamme varmistaaksemme, että tällaisia ​​tapauksia ei tapahdu tulevaisuudessa. Tässä tapauksessa tämä sisältää (mutta ei rajoitu) seuraavat asiat:

Olemme jo saaneet päätökseen

• Korjattu piilevä koodivirhe Azure AD -taustajärjestelmän SDP-järjestelmässä.
• Korjattiin olemassa oleva palautusjärjestelmä, jotta viimeiset tunnetut hyvät metatiedot voidaan palauttaa suojaamaan korruptiolta.
• Laajenna palautusoperaatioiden laajuutta ja tiheyttä.

Loput vaiheet sisältävät

• Käytä lisäsuojauksia Azure AD -palvelun taustajärjestelmän SDP-järjestelmään estääksesi tässä tunnistetut ongelmat.
• Nopeuta Azure AD -varmuuskopioiden todennusjärjestelmän käyttöönottoa kaikissa keskeisissä palveluissa ensisijaisena tavoitteena vähentääksesi merkittävästi samantyyppisten ongelmien vaikutusta tulevaisuudessa.
• Sisäänrakennetut Azure AD -skenaariot automatisoituun viestintäputkeen, joka lähettää alustavan viestinnän vaikutuksesta kärsiville asiakkaille 15 minuutin kuluessa.

Antaa palautetta: Auta meitä parantamaan Azure-asiakasviestintäkokemusta vastaamalla kyselyymme: https://aka.ms/AzurePIRSurvey

kautta ZDNet