# Recuperarea Outlook de la Microsoft a continuat să eșueze sub trafic

Published: 2026-11-13

Întreruperea serviciului de e-mail al Microsoft din 12-13 noiembrie a expus o buclă de recuperare: serverele returnate puteau deveni din nou inaccesibile sub trafic. La termenul limită aprobat din 13 noiembrie, ora 11:04:50 UTC, recuperarea a progresat în anumite părți din Asia Pacific, în timp ce problemele intermitente și munca în altă parte au rămas. Această continuare explică dependențele și măsurile de siguranță pentru e-mailurile întârziate.

Canonical: https://thedailydiff.dev/ro/video/2026-11-13-microsoft-recovery-loop/

## Ce acoperă acest videoclip

- Verificați dependența backend a fiecărei operațiuni: majoritatea funcționalităților Teams de bază și accesul direct la fișierele SharePoint au rămas funcționale, în timp ce funcțiile dependente de Exchange au fost afectate.
- Microsoft a raportat că serverele returnate puteau deveni din nou inaccesibile atunci când traficul ajungea la ele; explicația sa privind componenta de procesare a stării a rămas o ipoteză.
- Timpul de expirare extins de patruzeci și opt de ore pentru e-mail a fost destinat să păstreze e-mailurile întârziate în timpul procesării cozii și a restanțelor. Nu a fost un termen limită de reparație sau o garanție universală de livrare.
- Recomandările obișnuite de limitare a Graph recomandă respectarea Retry-After și a backoff-ului exponențial atunci când acest antet lipsește; nu diagnostichează sau repară acest incident.

## Întrebări și răspunsuri

### De ce ar putea eșua din nou serverele de e-mail returnate de Microsoft sub trafic?

Microsoft a raportat că serverele returnate ar putea deveni din nou inaccesibile odată ce primeau trafic. Investigația sa a descris procese supraîncărcate și o posibilă problemă într-o componentă de procesare a stării serverului, dar declanșatorul inițial aștepta încă un raport final de incident. Episodul ilustrează conceptual secvența raportată de returnare, muncă și recădere; nu pretinde o arhitectură internă dovedită sau o cauză principală finală.

### De ce ar putea funcționa apelurile Teams în timp ce funcțiile de calendar eșuau?

Majoritatea apelurilor, întâlnirilor și chaturilor Teams de bază au rămas funcționale conform notificării extinse a Microsoft privind starea serviciului. Scenariile de calendar și programare depindeau de Exchange Online și ar putea eșua în timpul întreruperii. Accesul direct la fișierele SharePoint a rămas, de asemenea, funcțional. Distincția utilă la nivel de aplicație este dependența din spatele unei operațiuni, mai degrabă decât tratarea fiecărei funcții sub un logo de produs ca având aceeași stare de eșec.

### A stabilit timeout-ul de patruzeci și opt de ore pentru e-mail un termen limită de reparație?

Microsoft a extins fereastra de expirare a e-mailului pentru a păstra mesajele întârziate, prioritizând în același timp procesarea cozii și a restanțelor. Acest lucru a oferit e-mailurilor întârziate mai mult timp în timpul recuperării. Notificarea publică nu a furnizat un termen limită de reparație de patruzeci și opt de ore și nicio garanție că fiecare mesaj va ajunge la destinatarul său. O notificare în așteptare sau în coadă a necesitat, prin urmare, o livrare sau o verificare reală a rezultatului înainte ca un flux de lucru sensibil la timp să se poată baza pe aceasta.

### Cum a afectat întreruperea Exchange aplicațiile Microsoft Graph?

Cererile pentru e-mail, calendar și contacte Exchange Online ar putea expira conform Microsoft. O aplicație ar putea întâmpina rezultate diferite în cadrul operațiunilor cu dependențe subiacente diferite. Episodul recomandă verificarea dependenței reale a serviciului operațiunii. Documentația separată a Microsoft privind limitarea obișnuită discută despre respectarea Retry-After și a backoff-ului exponențial atunci când acest antet lipsește; aceste politici nu stabilesc cauza acestui incident și nu promit restabilirea serviciului.

### Care a fost verdictul The Daily Diff privind recuperarea Microsoft?

Verdictul The Daily Diff a fost NECESITĂ REVIZUIRE. Niko a menținut recuperarea sub revizuire deoarece actualizările Microsoft au descris servere returnate eșuând sub trafic. Serviciul susținut cu muncă reală venind a fost testul util de recuperare. Cauza inițială a rămas deschisă la termenul limită de raportare al episodului, Microsoft promițând un raport complet de incident și acțiuni de apărare în profunzime după atenuare.

## Capitole

- 0:00 De ce au eșuat din nou serverele returnate?
- 0:19 Ce funcții depindeau de Exchange?
- 1:03 Cum supraîncarcă lipsa capacității un serviciu?
- 1:34 Ce a încercat Microsoft prima dată?
- 2:48 Ce se știa la termenul limită de raportare?
- 3:17 De ce ar putea eșua o cerere Graph?
- 4:05 Ce oferă fereastra de e-mail de 48 de ore?
- 4:48 Ce ar trebui să demonstreze o recuperare susținută?

## Transcrierea tradusă

Tradus din narațiunea originală în engleză. Audio-ul și subtitrările disponibile sunt controlate de YouTube.

### De ce au eșuat din nou serverele returnate?

0:00 Microsoft a readus serverele de e-mail în funcțiune. Acestea ar putea înceta să mai răspundă din nou când traficul revenea. Iată continuarea pentru dezvoltatori. În acest videoclip, de ce recuperarea a continuat să eșueze? Și ce părți ale aplicației dvs. încă funcționau? Microsoft a acordat, de asemenea, e-mailurilor întârziate patruzeci și opt de ore. Ce vă aduce asta de fapt? Este vineri, treisprezece noiembrie, și acesta este The Daily Diff.

0:18 Exchange Online este serviciul de e-mail găzduit de Microsoft, iar alte funcții Microsoft

### Ce funcții depindeau de Exchange?

0:22 365 depind de el. Iată distincția utilă de pe pagina de stare a Microsoft. Apelurile și chaturile de grup din Teams au funcționat în mare parte. Funcțiile de calendar și cererile de date din cutia poștală ar putea eșua. Verificați dependența pe care o utilizează de fapt aplicația dvs. Asta înseamnă că o întâlnire poate avea loc în timp ce calendarul refuză să coopereze. Accesul direct la fișierele din SharePoint a rămas, de asemenea, funcțional, în timp ce unele funcții de partajare au fost afectate.

0:42 Logo-ul de pe fereastră vă spune foarte puțin despre ce backend are nevoie următorul dvs. clic. Întreruperea a început joi, Microsoft investigând inițial accesul la cutiile poștale în America. Apoi a confirmat că utilizatorii din orice regiune ar putea fi afectați. CNN a raportat probleme la bănci, guverne și instanțe. Un e-mail lipsă este neplăcut până când munca reală a cuiva depinde de sosirea acestuia. Explicația inițială a Microsoft a fost o pierdere de servere disponibile. Munca pe care ar fi trebuit să o gestioneze acele mașini a solicitat infrastructura rămasă.

### Cum supraîncarcă lipsa capacității un serviciu?

1:06 Puteți supraîncărca un serviciu cu cerere obișnuită atunci când capacitatea sa dispare. Coada se lungește chiar dacă nimeni nu a descoperit brusc o pasiune pentru trimiterea de e-mailuri. Compania a investigat apoi verificările automate de sănătate. Aceste verificări ajută la deciderea dacă un server poate prelua muncă. Microsoft a declarat că o componentă care procesează starea serverului ar putea fi implicată. Aceasta este o ipoteză dintr-o investigație încă în curs. Nu avem un raport final de incident care să explice exact de ce acele servere au devenit inițial indisponibile. Actualizările seamănă cu o tură de gardă devenind progresiv mai puțin interesată de micul dejun.

1:29 Pauză implementări. Mută trafic. Reporniți serverele. Microsoft a validat o verificare alternativă de sănătate care a readus un subset,

### Ce a încercat Microsoft prima dată?

1:37 și a pregătit sisteme automate pentru a detecta și reporni mașinile care nu răspund. Fiecare actualizare a descris o încercare de a recupera capacitatea. Apoi a venit rândul care explică bucla de recuperare. Microsoft a declarat că serverele returnate în serviciu ar putea deveni din nou inaccesibile odată ce primeau trafic. O mașină ar putea reveni, primi muncă reală și înceta să mai răspundă. Această observație este o dovadă mai puternică decât teoria încrezătoare a oricui din răspunsuri. Imaginați-vă același server prin aceste stări.

1:59 Indisponibil. Returnat în serviciu. Preia trafic. Inaccesibil din nou. Acest lucru ilustrează relatarea Microsoft. Ce declanșează acea ultimă tranziție rămâne fără răspuns. O repornire poate produce o îmbunătățire temporară în timp ce condiția care înfrânge serverul rămâne nerezolvată. Sfaturile de a-l opri și reporni încep să încarce ore suplimentare. Inginerii trebuie să verifice ce se întâmplă după ce munca revine.

2:18 Clienții au nevoie ca serviciul să continue să funcționeze prin următoarea cerere, și următoarea. Microsoft a limitat anumite trafic care ajungea la infrastructura afectată în unele locații. De asemenea, a reconstruit un subset de servere folosind o configurație anterioară pentru a testa dacă ar rămâne receptive. Acestea au fost raportate ca experimente de atenuare. Pauza implementărilor în timpul recuperării nu ne oferă nicio dovadă că o implementare de vineri a cauzat întreruperea inițială. Până la actualizarea de vineri a Microsoft, la ora 11:04 UTC, acțiunile de recuperare s-au încheiat în părți din Asia Pacific.

2:39 Traficul revenea treptat, cu îmbunătățiri în accesul la cutia poștală și procesarea e-mailurilor întârziate. Unii utilizatori ar putea încă întâmpina probleme intermitente, iar recuperarea în altă parte a continuat. Acesta este termenul nostru limită de raportare. Microsoft a declarat că nu are dovezi de activitate malițioasă,

### Ce se știa la termenul limită de raportare?

2:48 și a promis un raport complet de incident după atenuare. Aș aștepta acel raport înainte de a desemna un răufăcător. Munca de detectiv pe internet vă poate da un vinovat înainte de a fi terminat chiar și reîmprospătarea paginii. Pentru dezvoltatori, Microsoft Graph face dependența deosebit de ușor de ratat. Cererile sale pentru e-mail, calendar și contacte Exchange ar putea expira. Aplicația dvs. poate apela Graph cu succes pentru o operațiune și poate eșua la alta. O cerere nerelevantă reușită vă spune puțin despre dacă operațiunea de cutie poștală de care are nevoie utilizatorul dvs. se va finaliza. Pagina de stare a avut nevoie chiar de propria sa cale de evadare.

3:10 Microsoft a publicat informațiile despre incident pentru că administratorii ar putea să nu poată încărca centrul de administrare pentru a citi starea serviciului. Când tabloul de bord pentru a afla ce este stricat depinde de ceea ce este stricat, tabloul de bord s-a alăturat incidentului. Păstrați un link de stare în afara benzii disponibil.

### De ce ar putea eșua o cerere Graph?

3:20 Pentru limitarea obișnuită a Graph, recomandarea Microsoft este să respectați întârzierea de reîncercare atunci când o cerere primește un răspuns de prea multe cereri, și să utilizați backoff exponențial atunci când acest antet lipsește. Această recomandare gestionează limitarea. Nu diagnostichează această întrerupere și nu promite că reîncercările vor restabili serviciul. Acum cele patruzeci și opt de ore. Pagina de stare extinsă a Microsoft spune că a prioritizat procesarea cozii și a restanțelor și a extins fereastra de expirare a e-mailului pentru a păstra mesajele întârziate. Acest lucru oferă e-mailurilor întârziate mai mult timp în timpul recuperării. Setează o fereastră de expirare a e-mailului.

3:46 Microsoft nu a dat un termen limită de patruzeci și opt de ore pentru remedierea serviciului, și nicio garanție că fiecare mesaj va ajunge. Așa că păstrați afirmațiile de livrare oneste. O notificare întârziată nu a dispărut neapărat, și un mesaj în coadă nu a ajuns neapărat la destinatarul său. Pentru munca sensibilă la timp, verificați rezultatul printr-un canal independent aprobat. O fereastră client este o chitanță de livrare optimistă atunci când backend-ul se recuperează încă. Ceea ce lasă multe de citit în raportul final de incident.

### Ce oferă fereastra de e-mail de 48 de ore?

4:05 Dacă preferați să citiți acest lucru decât să mă auziți spunând-o, diff-ul ajunge în căsuța dvs. de e-mail în fiecare dimineață, gratuit la the daily diff dot dev, link mai jos. Așa că verdictul de astăzi, NECESITĂ REVIZUIRE. Aș menține recuperarea sub revizuire deoarece propriile actualizări ale Microsoft au arătat servere returnate eșuând sub trafic. Testul util este serviciul susținut cu muncă reală venind. Până la raportul final, cauza inițială rămâne deschisă. Și asta e diff-ul pentru astăzi.

4:28 Sunt Niko de la Axrisi. Fuzionați responsabil. Microsoft a readus serverele de e-mail în funcțiune, dar acestea ar putea deveni din nou inaccesibile sub trafic, ceea ce a dus la o buclă de recuperare. Acesta este The Daily Diff, 13 noiembrie. Dacă ați fost afectat de recenta întrerupere de e-mail a Microsoft din 12-13 noiembrie, poate că ați văzut serverele dvs. revenind la funcționare, doar pentru a eșua din nou sub trafic. Voi aborda acest lucru în profunzime. Am explicat dependențele, am verificat ce funcții Teams și SharePoint ar putea funcționa în continuare și am explicat de ce Microsoft a stabilit o fereastră de timeout de 48 de ore pentru e-mail. Am menționat The Daily Diff de la Axrisi și verdictul meu NEEDS REVIEW privind recuperarea, plus întrebările esențiale la care trebuie să răspundeți în raportul de incident.

### Ce ar trebui să demonstreze o recuperare susținută?

4:49 Microsoft a explicat că procesele supraîncărcate și o posibilă problemă într-o componentă de procesare a stării serverului ar putea fi cauze, dar cauza inițială așteaptă încă un raport final de incident. Testul util este serviciul susținut cu muncă reală venind. Până la raportul final, cauza inițială rămâne deschisă. Am subliniat că apelurile Teams și accesul direct la SharePoint au rămas funcționale, dar calendarul și e-mailul au eșuat. Această distincție de dependență este esențială. Am explicat că timeout-ul de 48 de ore pentru e-mail a fost pentru a păstra mesajele întârziate, nu o garanție de livrare sau un termen limită de reparație. De asemenea, am sugerat utilizatorilor să utilizeze un canal independent pentru munca sensibilă la timp, în loc să se bazeze pe chitanțele de livrare optimiste ale clientului în timpul recuperării backend. Niko, de la Axrisi, a încheiat episodul cu îndemnul Merge responsibly, iar verdictul The Daily Diff, NEEDS REVIEW, a subliniat că recuperarea Microsoft necesita o monitorizare continuă din cauza serverelor care eșuau sub trafic. Incidentul a scos în evidență necesitatea unor linkuri de stare în afara benzii și a unui proces robust de recuperare care să poată gestiona revenirea traficului.

## Surse

- [ExpandedMicrosoftservicehealth, reportingcutoffNovember13 11:04:50UTC; earlier10:01:07observationshistorical](https://status.cloud.microsoft/) — Microsoft
- [Returned servers can become unresponsive again once they receive traffic](https://x.com/MSFT365Status/status/2121031935010951521) — Microsoft 365 Status
- [Health-processing component investigation hypothesis](https://x.com/MSFT365Status/status/2120974801388904932) — Microsoft 365 Status
- [Alternative health check returned a subset of servers](https://x.com/MSFT365Status/status/2120985048337830246) — Microsoft 365 Status
- [Isolate, restart and reintroduce traffic to test stability](https://x.com/MSFT365Status/status/2121002505911857577) — Microsoft 365 Status
- [Unavailable servers strain remaining infrastructure](https://x.com/MSFT365Status/status/2120962673911181437) — Microsoft 365 Status
- [Initial Exchange mailbox-access investigation in the Americas](https://x.com/MSFT365Status/status/2120938282204688468) — Microsoft 365 Status
- [Users in any region may be affected](https://x.com/MSFT365Status/status/2120941584220827979) — Microsoft 365 Status
- [Email timeout extended to preserve delayed messages](https://x.com/MSFT365Status/status/2121172248241348867) — Microsoft 365 Status
- [Paused deployments, traffic redistribution and server restarts](https://x.com/MSFT365Status/status/2120957934607700161) — Microsoft 365 Status
- [Independent live reporting on the Microsoft email disruption](https://www.cnn.com/2026/11/12/business/live-news/microsoft-global-outage-intl-hnk) — CNN
- [Microsoft Graph throttling guidance](https://learn.microsoft.com/en-us/graph/throttling) — Microsoft Learn
- [Exchange Online service description](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-service-description) — Microsoft 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.](https://commons.wikimedia.org/wiki/File:Satya_Nadella.jpg) — OFFICIAL LEWEB PHOTOS
- [Portrait-only CC BY 2.0 licence; separate from third-party source/cartoon rights](https://creativecommons.org/licenses/by/2.0/) — Creative 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.](https://imgflip.com/memetemplate/234202281/AJ-Styles--Undertaker) — 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.](https://giphy.com/gifs/the-simpsons-sideshow-bob-RSOUOj8H9A3Xq) — The Simpsons / 20th Television / Disney; GIPHY source hosting