Microsofts Outlook-gjenoppretting fortsatte å feile under trafikk

Hva denne videoen dekker

• Kontroller backend-avhengigheten til hver operasjon: det meste av Teams-kjernefunksjonaliteten og direkte SharePoint-filtilgang forble funksjonell, mens Exchange-avhengige funksjoner ble svekket.
• Microsoft rapporterte at returnerte servere kunne bli utilgjengelige igjen når trafikken nådde dem; forklaringen om helsebehandlingskomponenten forble en hypotese.
• Den utvidede førtiåtte timers e-posttidsavbruddet var ment å bevare forsinket e-post under kø- og etterslepsbehandling. Det var ingen reparasjonsfrist eller universell leveringsgaranti.
• Vanlig Graph-strupeveiledning anbefaler å respektere Retry-After og eksponentiell backoff når denne headeren mangler; den diagnostiserer eller reparerer ikke denne hendelsen.

Oversatt transkripsjon

Oversatt fra den originale engelske fortellingen. Tilgjengelig lyd og undertekster kontrolleres av YouTube.

Hvorfor feilet returnerte servere igjen?

0:00 Microsoft returnerte e-postservere til tjeneste. De kunne slutte å svare igjen når trafikken kom tilbake. Her er utvikleroppfølgingen. I denne videoen, hvorfor fortsatte gjenopprettingen å feile? Og hvilke deler av appen din fungerte fortsatt? Microsoft ga også forsinket e-post førtiåtte timer. Hva kjøper det deg egentlig? Det er fredag trettende november, og dette er The Daily Diff.

0:18 Exchange Online er Microsofts vertsbaserte e-posttjeneste, og andre Microsoft tre

Hvilke funksjoner var avhengige av Exchange?

0:22 sekstifem funksjoner avhenger av den. Her er det nyttige skillet fra Microsofts statusside. Teams-anrop og gruppechatter fungerte stort sett. Kalenderfunksjoner og forespørsler om postboksdata kunne feile. Sjekk avhengigheten applikasjonen din faktisk bruker. Det betyr at et møte fortsatt kan finne sted mens kalenderen nekter å samarbeide. Direkte tilgang til filer i SharePoint forble også funksjonell, mens noen delingsfunksjoner ble påvirket.

0:42 Logoen på vinduet forteller deg svært lite om hvilken backend ditt neste klikk trenger. Forstyrrelsen begynte torsdag, med Microsoft som først undersøkte postbokstilgang i Amerika. De bekreftet deretter at brukere i alle regioner kunne bli berørt. CNN rapporterte problemer på tvers av banker, myndigheter og domstoler. En manglende e-post er ubeleilig til noens virkelige arbeid avhenger av at den kommer. Microsofts tidlige forklaring var tap av tilgjengelige servere.

Hvordan overbelaster manglende kapasitet en tjeneste?

1:06 Arbeidet som disse maskinene skulle ha håndtert, belastet den gjenværende infrastrukturen. Du kan overbelaste en tjeneste med vanlig etterspørsel når dens kapasitet forsvinner. Køen blir lengre selv om ingen plutselig har oppdaget en lidenskap for å sende e-post. Selskapet undersøkte deretter automatiserte helsekontroller. Disse kontrollene hjelper til med å avgjøre om en server kan ta arbeid. Microsoft sa at en komponent som behandler serverhelse, kunne være involvert. Det er en hypotese fra en undersøkelse som fortsatt pågår.

1:29 Vi har ingen endelig hendelsesrapport som forklarer nøyaktig hvorfor disse serverne først ble utilgjengelige. Oppdateringene leses som et vaktlag som blir stadig

Hva prøvde Microsoft først?

1:37 mindre interessert i frokost. Sett distribusjoner på pause. Flytt trafikk. Start servere på nytt. Microsoft validerte en alternativ helsekontroll som brakte en delmengde tilbake, og forberedte automatiserte systemer for å oppdage og starte utilgjengelige maskiner på nytt. Hver oppdatering beskrev et forsøk på å gjenopprette kapasitet. Så kom linjen som forklarer gjenopprettingsløkken. Microsoft sa at serverne som ble returnert til tjeneste, kunne bli utilgjengelige igjen når de mottok trafikk.

1:59 En maskin kunne komme tilbake, motta ekte arbeid og slutte å svare. Den observasjonen er sterkere bevis enn noens sikre teori i svarene. Se for deg den samme serveren gjennom disse tilstandene. Utilgjengelig. Returnert til tjeneste. Tar trafikk. Utilgjengelig igjen. Dette illustrerer Microsofts beretning. Hva som utløser den siste overgangen, forblir ubesvart. En omstart kan gi en midlertidig

2:18 forbedring mens tilstanden som beseirer serveren forblir uløst. Rådet om å slå den av og på igjen begynner å belaste overtid. Ingeniører må sjekke hva som skjer etter at arbeidet kommer tilbake. Kunder trenger at tjenesten fortsetter å fungere gjennom neste forespørsel, og den neste. Microsoft begrenset viss trafikk som nådde berørt infrastruktur på noen steder. De bygde også om en delmengde av servere ved hjelp av en tidligere konfigurasjon for å

2:39 teste om de ville forbli responsive. Dette var rapporterte avbøtende eksperimenter. Å sette distribusjoner på pause under gjenoppretting gir oss ingen bevis på at en fredagsdistribusjon forårsaket det opprinnelige bruddet.

Hva var kjent ved rapporteringsfristen?

2:48 Ved Microsofts fredagsoppdatering klokka elleve null fire UTC, hadde gjenopprettingstiltakene blitt fullført i deler av Asia/Stillehavsregionen. Trafikken var gradvis tilbake, med forbedringer i postbokstilgang og forsinket e-postbehandling. Noen brukere kunne fortsatt oppleve periodiske problemer, og gjenoppretting andre steder fortsatte. Det er vår rapporteringsfrist. Microsoft sa at de ikke hadde bevis på ondsinnet aktivitet, og lovet en fullstendig hendelsesrapport etter avbøting.

3:10 Jeg ville ventet på den rapporten før jeg tildelte en skurk. Internett-detektivarbeid kan gi deg en synder før du engang har fullført oppdateringen av siden. For utviklere gjør Microsoft Graph avhengigheten spesielt lett å overse.

Hvorfor kunne en Graph-forespørsel feile?

3:20 Forespørslene om Exchange-e-post, kalender og kontakter kunne få tidsavbrudd. Applikasjonen din kan ringe Graph vellykket for én operasjon og feile på en annen. En vellykket urelatert forespørsel forteller deg lite om hvorvidt postboksoperasjonen brukeren din trenger vil fullføres. Statussiden trengte til og med sin egen rømningsvei. Microsoft publiserte hendelsesinformasjon offentlig fordi administratorer kanskje ikke var i stand til å laste inn administrasjonssenteret for å lese tjenestehelse. Når dashbordet for å finne ut hva som er ødelagt, avhenger av hva som er ødelagt,

3:46 har dashbordet blitt en del av hendelsen. Hold en out-of-band statuslenke tilgjengelig. For vanlig Graph-strupebegrensning sier Microsofts veiledning at man skal respektere ventetiden når en forespørsel får et for mange forespørsler-svar, og bruke eksponentiell tilbakekobling når den headeren mangler. Den veiledningen håndterer strupebegrensning. Den diagnostiserer ikke dette bruddet eller lover at nye forsøk gjenoppretter tjenesten. Nå de førtiåtte timene.

Hva kjøper det 48-timers postvinduet?

4:05 Microsofts utvidede statusside sier at de prioriterte kø- og etterslepsbehandling og utvidet e-postens tidsavbruddsvindu for å bevare forsinkede meldinger. Det gir forsinket e-post mer tid under gjenoppretting. Det setter et tidsavbruddsvindu for e-post. Microsoft ga ingen førtiåtte timers frist for å fikse tjenesten, og ingen garanti for at hver melding ville komme frem. Så hold leveringskravene ærlige. En forsinket varsling har ikke nødvendigvis forsvunnet,

4:28 og en køet melding har ikke nødvendigvis nådd mottakeren. For tidssensitivt arbeid, bekreft resultatet gjennom en godkjent uavhengig kanal. Et klientvindu er en optimistisk leveringskvittering når backend fortsatt gjenoppretter. Som etterlater mye å lese i den eventuelle hendelsesrapporten. Hvis du heller vil lese dette enn å høre meg si det, lander diffen i innboksen din hver morgen, gratis på the daily diff dot dev, lenke nedenfor. Så dagens dom, NEEDS REVIEW.

Hva måtte vedvarende gjenoppretting bevise?

4:49 Jeg ville holdt gjenopprettingen under vurdering fordi Microsofts egne oppdateringer viste at returnerte servere feilet under trafikk. Den nyttige testen er vedvarende tjeneste med ekte arbeid som kommer gjennom. Inntil den endelige rapporten forblir den opprinnelige årsaken åpen. Og det er diffen for i dag. Jeg er Niko fra Axrisi. Flett ansvarlig.

Kilder

1. ExpandedMicrosoftservicehealth, reportingcutoffNovember13 11:04:50UTC; earlier10:01:07observationshistoricalMicrosoft
2. Returned servers can become unresponsive again once they receive trafficMicrosoft 365 Status
3. Health-processing component investigation hypothesisMicrosoft 365 Status
4. Alternative health check returned a subset of serversMicrosoft 365 Status
5. Isolate, restart and reintroduce traffic to test stabilityMicrosoft 365 Status
6. Unavailable servers strain remaining infrastructureMicrosoft 365 Status
7. Initial Exchange mailbox-access investigation in the AmericasMicrosoft 365 Status
8. Users in any region may be affectedMicrosoft 365 Status
9. Email timeout extended to preserve delayed messagesMicrosoft 365 Status
10. Paused deployments, traffic redistribution and server restartsMicrosoft 365 Status
11. Independent live reporting on the Microsoft email disruptionCNN
12. Microsoft Graph throttling guidanceMicrosoft Learn
13. Exchange Online service descriptionMicrosoft Learn
14. Satya Nadella portrait by OFFICIAL LEWEB PHOTOS (2013), CC BY 2.0. Whole portrait-based artwork adapted by cropping, background removal, resizing and text/composition; vendor identity only, no endorsement or current reaction.OFFICIAL LEWEB PHOTOS
15. Portrait-only CC BY 2.0 licence; separate from third-party source/cartoon rightsCreative Commons
16. WWE still. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.WWE / Imgflip source hosting
17. The Simpsons/Bob GIF. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.The Simpsons / 20th Television / Disney; GIPHY source hosting