Microsofts Outlook-återställning misslyckades upprepade gånger under trafik
Microsofts e-poststörning den 12–13 november avslöjade en återställningsslinga: återställda servrar kunde bli oresponsiva igen under trafik.
Microsofts e-poststörning den 12–13 november avslöjade en återställningsslinga: återställda servrar kunde bli oresponsiva igen under trafik. Vid den godkända tidsgränsen kl. 11:04:50 UTC den 13 november hade återställningen framskridit i delar av Asien och Stillahavsområdet medan intermittent problem och arbete på andra ställen återstod. Denna uppföljning förklarar beroenden och skydd för fördröjd e-post.
Läs den skrivna upplagan (engelska) ↗
Vad den här videon täcker
- Kontrollera backend-beroendet för varje operation: de flesta kärnfunktionerna i Teams och direkt SharePoint-filåtkomst förblev funktionella, medan Exchange-beroende funktioner var nedsatta.
- Microsoft rapporterade att återställda servrar kunde bli oresponsiva igen när trafik nådde dem; deras förklaring av hälsoprocesseringskomponenten förblev en hypotes.
- Den förlängda fyrtioåtta timmars e-posttidsgränsen var avsedd att bevara fördröjd post under kö- och eftersläpsbehandling. Det var ingen reparationsfrist eller universell leveransgaranti.
- Vanlig Graph-begränsningsvägledning rekommenderar att man följer Retry-After och exponentiell backoff när den rubriken saknas; den diagnostiserar eller reparerar inte denna incident.
Frågor och svar
Varför kunde Microsofts återställda e-postservrar misslyckas igen under trafik?
Microsoft rapporterade att återställda servrar kunde bli oresponsiva igen när de fick trafik. Deras utredning beskrev överväldigade processer och ett möjligt problem i en komponent som behandlar serverhälsa, men den initiala utlösaren väntade fortfarande på en slutgiltig incidentrapport. Avsnittet illustrerar den rapporterade sekvensen av återkomst, arbete och återfall konceptuellt; det gör inte anspråk på en beprövad intern arkitektur eller slutgiltig grundorsak.
Varför kunde Teams-samtal fungera medan kalenderfunktioner misslyckades?
De flesta kärnfunktionerna i Teams-samtal, möten och chattar förblev funktionella enligt Microsofts utökade meddelande om tjänstehälsa. Kalender- och schemaläggningsscenarion var beroende av Exchange Online och kunde misslyckas under störningen. Direkt SharePoint-filåtkomst förblev också funktionell. Den användbara skillnaden på applikationsnivå är beroendet bakom en operation, snarare än att behandla varje funktion under en produktlogotyp som att dela samma felstatus.
Satte den fyrtioåtta timmars e-posttidsgränsen en reparationsfrist?
Microsoft förlängde e-posttidsgränsen för att bevara fördröjda meddelanden samtidigt som de prioriterade kö- och eftersläpsbehandling. Det gav fördröjd post mer tid under återställningen. Det offentliga meddelandet angav ingen fyrtioåtta timmars reparationsfrist och ingen garanti för att varje meddelande skulle nå sin mottagare. En väntande eller köad avisering krävde därför en faktisk leverans- eller resultatkontroll innan ett tidskänsligt arbetsflöde kunde förlita sig på det.
Hur påverkade Exchange-störningen Microsoft Graph-applikationer?
Begäranden om Exchange Online-e-post, kalender och kontakter kunde ta slut enligt Microsoft. En applikation kunde stöta på olika resultat över operationer med olika underliggande beroenden. Avsnittet rekommenderar att man kontrollerar operationens faktiska tjänstberoende. Microsofts separata dokumentation om vanlig begränsning diskuterar att respektera Retry-After och exponentiell backoff när den rubriken saknas; dessa policyer fastställer inte denna incidents orsak eller lovar återställd tjänst.
Vad var The Daily Diffs dom om Microsofts återställning?
The Daily Diffs dom var BEHÖVER ÖVERSYN. Niko höll återställningen under översyn eftersom Microsofts uppdateringar beskrev att återställda servrar misslyckades under trafik. Ihållande tjänst med verkligt arbete som kommer igenom var det användbara återställningstestet. Den initiala orsaken förblev öppen vid avsnittets rapporteringsavskärning, med Microsoft som lovade en fullständig incidentrapport och djupgående åtgärder efter begränsningen.
Översatt transkription
Översatt från den ursprungliga engelska berättelsen. Tillgängligt ljud och undertexter styrs av YouTube.
Varför misslyckades återställda servrar igen?
0:00 Microsoft återställde e-postservrar till tjänsten. De kunde sluta svara igen när trafiken återvände. Här är utvecklaruppföljningen. I den här videon, varför fortsatte återställningen att misslyckas? Och vilka delar av din app fungerade fortfarande? Microsoft gav också fördröjd e-post fyrtioåtta timmar. Vad vinner man egentligen med det? Det är fredagen den trettonde november, och detta är The Daily Diff.
0:18 Exchange Online är Microsofts hostade e-posttjänst, och andra Microsoft 365-funktioner
Vilka funktioner var beroende av Exchange?
0:22 är beroende av den. Här är den användbara skillnaden från Microsofts statussida. Teams-samtal och gruppchattar fungerade mestadels. Kalenderfunktioner och begäranden om postlådedata kunde misslyckas. Kontrollera vilket beroende din applikation faktiskt använder. Det betyder att ett möte fortfarande kan äga rum medan kalendern vägrar att samarbeta. Direkt åtkomst till filer i SharePoint förblev också funktionell, medan vissa delningsfunktioner påverkades.
0:42 Logotypen på fönstret säger väldigt lite om vilken backend ditt nästa klick behöver. Störningen började på torsdagen, med Microsoft som initialt undersökte postlådeåtkomst i Nord- och Sydamerika. De bekräftade sedan att användare i vilken region som helst kunde påverkas. CNN rapporterade problem inom banker, regeringar och domstolar. En missad e-post är obekvämt tills någons riktiga arbete beror på att den anländer. Microsofts tidiga förklaring var en förlust av tillgängliga servrar.
Hur överbelastar saknad kapacitet en tjänst?
1:06 Arbetet som de maskinerna skulle ha hanterat belastade den kvarvarande infrastrukturen. Du kan överbelasta en tjänst med vanlig efterfrågan när dess kapacitet försvinner. Kön blir längre även om ingen plötsligt har upptäckt en passion för att skicka e-post. Företaget undersökte sedan automatiserade hälsokontroller. Dessa kontroller hjälper till att avgöra om en server kan ta emot arbete. Microsoft sa att en komponent som behandlar serverhälsa kunde vara inblandad. Det är en hypotes från en utredning som fortfarande pågår.
1:29 Vi har ingen slutgiltig incidentrapport som exakt förklarar varför de servrarna först blev otillgängliga. Uppdateringarna låter som ett jourpass som blir allt
Vad provade Microsoft först?
1:37 mindre intresserade av frukost. Pausa driftsättningar. Flytta trafik. Starta om servrar. Microsoft validerade en alternativ hälsokontroll som återförde en delmängd, och förberedde automatiserade system för att upptäcka och starta om oresponsiva maskiner. Varje uppdatering beskrev ett försök att återställa kapacitet. Sedan kom raden som förklarar återställningsslingan. Microsoft sa att servrarna som återgått i tjänst kunde bli oresponsiva igen när de fick trafik.
1:59 En maskin kunde komma tillbaka, ta emot riktigt arbete och sluta svara. Den observationen är starkare bevis än någons självsäkra teori i svaren. Föreställ dig samma server genom de tillstånden. Otillgänglig. Återställd till tjänst. Tar emot trafik. Oresponsiv igen. Detta illustrerar Microsofts redogörelse. Vad som utlöser den sista övergången är fortfarande obesvarat. En omstart kan ge en tillfällig
2:18 förbättring medan det tillstånd som besegrar servern förblir olöst. Rådet att stänga av och slå på den igen börjar kosta övertid. Ingenjörer måste kontrollera vad som händer efter att arbetet återvänder. Kunder behöver tjänsten för att fortsätta fungera genom nästa begäran, och nästa. Microsoft begränsade viss trafik som nådde den berörda infrastrukturen på vissa platser. De byggde också om en delmängd av servrar med en tidigare konfiguration för att
2:39 testa om de skulle förbli responsiva. Dessa rapporterades som begränsningsexperiment. Att pausa driftsättningar under återhämtning ger oss inga bevis för att en fredags- driftsättning orsakade det ursprungliga avbrottet.
Vad var känt vid rapporteringsavskärningen?
2:48 Vid Microsofts fredagsuppdatering klockan elva noll fyra UTC, hade återställningsåtgärder avslutats i delar av Asien och Stillahavsområdet. Trafiken återvände gradvis, med förbättringar i postlådeåtkomst och fördröjd e-postbehandling. Vissa användare kunde fortfarande uppleva intermittenta problem, och återställningen fortsatte på andra ställen. Det är vår rapporteringsavskärning. Microsoft sa att de inte hade några bevis på skadlig aktivitet, och lovade en fullständig incidentrapport efter begränsningen.
3:10 Jag skulle vänta på den rapporten innan jag tilldelar en skurk. Internetdetektivarbete kan ge dig en gärningsman innan du ens har hunnit uppdatera sidan. För utvecklare gör Microsoft Graph beroendet särskilt lätt att missa.
Varför kunde en Graph-begäran misslyckas?
3:20 Dess begäranden om Exchange-e-post, kalender och kontakter kunde ta slut. Din applikation kan anropa Graph framgångsrikt för en operation och misslyckas med en annan. En framgångsrik orelaterad begäran säger dig lite om huruvida den postlådeoperation din användare behöver kommer att slutföras. Statussidan behövde till och med sin egen flyktväg. Microsoft publicerade incidentinformation offentligt eftersom administratörer kanske inte kunde ladda administratörscentret för att läsa tjänstens hälsa. När instrumentpanelen för att ta reda på vad som är trasigt är beroende av det som är trasigt,
3:46 har instrumentpanelen blivit en del av incidenten. Håll en utom-band-statuslänk tillgänglig. För vanlig Graph-begränsning säger Microsofts vägledning att man ska respektera återförsöks- fördröjningen när en begäran får ett svar om för många begäranden, och använda exponentiell backoff när den rubriken saknas. Den vägledningen hanterar begränsning. Den diagnostiserar inte detta avbrott eller lovar att återförsök återställer tjänsten. Nu de fyrtioåtta timmarna.
Vad vinner man med det 48-timmars postfönstret?
4:05 Microsofts utökade statussida säger att de prioriterade kö- och eftersläps- behandling och förlängde e-posttidsgränsen för att bevara fördröjda meddelanden. Det ger fördröjd post mer tid under återställningen. Det sätter ett e-posttidsgränsfönster. Microsoft gav ingen fyrtioåtta timmars deadline för att åtgärda tjänsten, och ingen garanti för att varje meddelande skulle komma fram. Så håll leveranspåståenden ärliga. En fördröjd avisering har inte nödvändigtvis försvunnit,
4:28 och ett köat meddelande har inte nödvändigtvis nått sin mottagare. För tidskänsligt arbete, verifiera resultatet via en godkänd oberoende kanal. Ett klientfönster är ett optimistiskt leveranskvitto när backend fortfarande återställs. Vilket lämnar mycket att läsa i den eventuella incidentrapporten. Om du hellre läser detta än hör mig säga det, landar diffen i din inkorg varje morgon, gratis på the daily diff dot dev, länk nedan. Så dagens dom, BEHÖVER ÖVERSYN.
Vad skulle en ihållande återhämtning behöva bevisa?
4:49 Jag skulle hålla återställningen under översyn eftersom Microsofts egna uppdateringar visade att återställda servrar misslyckades under trafik. Det användbara testet är ihållande tjänst med verkligt arbete som kommer igenom. Fram till den slutliga rapporten förblir den ursprungliga orsaken öppen. Och det är skillnaden för idag. Jag är Niko från Axrisi. Sammanfoga ansvarsfullt.
Källor
- ExpandedMicrosoftservicehealth, reportingcutoffNovember13 11:04:50UTC; earlier10:01:07observationshistoricalMicrosoft
- Returned servers can become unresponsive again once they receive trafficMicrosoft 365 Status
- Health-processing component investigation hypothesisMicrosoft 365 Status
- Alternative health check returned a subset of serversMicrosoft 365 Status
- Isolate, restart and reintroduce traffic to test stabilityMicrosoft 365 Status
- Unavailable servers strain remaining infrastructureMicrosoft 365 Status
- Initial Exchange mailbox-access investigation in the AmericasMicrosoft 365 Status
- Users in any region may be affectedMicrosoft 365 Status
- Email timeout extended to preserve delayed messagesMicrosoft 365 Status
- Paused deployments, traffic redistribution and server restartsMicrosoft 365 Status
- Independent live reporting on the Microsoft email disruptionCNN
- Microsoft Graph throttling guidanceMicrosoft Learn
- Exchange Online service descriptionMicrosoft Learn
- 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
- Portrait-only CC BY 2.0 licence; separate from third-party source/cartoon rightsCreative Commons
- 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
- 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



