Il ripristino di Outlook di Microsoft continuava a fallire sotto traffico

Contenuto di questo video

• Controllare la dipendenza backend di ogni operazione: la maggior parte delle funzionalità principali di Teams e l'accesso diretto ai file di SharePoint sono rimasti funzionali, mentre le funzionalità dipendenti da Exchange erano compromesse.
• Microsoft ha riferito che i server ripristinati potevano diventare nuovamente non reattivi quando il traffico li raggiungeva; la sua spiegazione del componente di elaborazione della salute è rimasta un'ipotesi.
• Il timeout esteso di quarantotto ore per l'email era inteso a preservare la posta ritardata durante l'elaborazione della coda e del backlog. Non era una scadenza di riparazione o una garanzia di consegna universale.
• Le normali linee guida per il throttling di Graph raccomandano di rispettare Retry-After e il backoff esponenziale quando tale intestazione è assente; non diagnostica o ripara questo incidente.

Trascrizione tradotta

Tradotto dalla narrazione originale inglese. L'audio e i sottotitoli disponibili sono controllati da YouTube.

Perché i server restituiti hanno fallito di nuovo?

0:00 Microsoft ha ripristinato i server di posta. Potevano smettere di rispondere di nuovo quando il traffico tornava. Ecco il follow-up per gli sviluppatori. In questo video, perché il ripristino continuava a fallire? E quali parti della tua app funzionavano ancora? Microsoft ha anche concesso quarantotto ore per le email in ritardo. Cosa si ottiene realmente con questo? È venerdì, tredici novembre, e questo è The Daily Diff.

0:18 Exchange Online è il servizio di posta elettronica ospitato da Microsoft, e altre funzionalità di Microsoft 365

Quali funzionalità dipendevano da Exchange?

0:22 dipendono da esso. Ecco la distinzione utile dalla pagina di stato di Microsoft. Le chiamate e le chat di gruppo di Teams funzionavano per lo più. Le funzionalità del calendario e le richieste di dati delle cassette postali potevano fallire. Controlla la dipendenza che la tua applicazione utilizza effettivamente. Ciò significa che una riunione può ancora svolgersi mentre il calendario si rifiuta di collaborare. Anche l'accesso diretto ai file in SharePoint è rimasto funzionale, mentre alcune funzionalità di condivisione sono state interessate.

0:42 Il logo sulla finestra ti dice molto poco su quale backend necessita il tuo prossimo clic. L'interruzione è iniziata giovedì, con Microsoft che inizialmente indagava l'accesso alle cassette postali nelle Americhe. Ha poi confermato che gli utenti in qualsiasi regione potevano essere interessati. La CNN ha riportato problemi in banche, governi e tribunali. Un'email mancante è scomoda finché il vero lavoro di qualcuno non dipende dal suo arrivo. La prima spiegazione di Microsoft è stata una perdita di server disponibili.

Come una capacità mancante sovraccarica un servizio?

1:06 Il lavoro che quelle macchine avrebbero dovuto gestire ha messo sotto pressione l'infrastruttura rimanente. È possibile sovraccaricare un servizio con la domanda ordinaria quando la sua capacità scompare. La coda si allunga anche se nessuno ha improvvisamente scoperto la passione per l'invio di email. La coda si allunga anche se nessuno ha improvvisamente scoperto la passione per l'invio di email. L'azienda ha quindi indagato sui controlli automatici della salute. Questi controlli aiutano a decidere se un server può accettare lavoro. Microsoft ha affermato che un componente che elabora lo stato del server potrebbe essere coinvolto. Questa è un'ipotesi da un'indagine ancora in corso.

1:29 Non abbiamo un rapporto finale sull'incidente che spieghi esattamente perché quei server sono diventati inizialmente non disponibili. Gli aggiornamenti sembrano un turno di reperibilità che diventa progressivamente

Cosa ha provato prima Microsoft?

1:37 meno interessato alla colazione. Metti in pausa le implementazioni. Sposta il traffico. Riavvia i server. Microsoft ha convalidato un controllo di integrità alternativo che ne ha ripristinato un sottoinsieme e ha preparato sistemi automatizzati per rilevare e riavviare le macchine non reattive. Ogni aggiornamento descriveva un tentativo di recuperare capacità. Poi è arrivata la frase che spiega il ciclo di ripristino. Microsoft ha affermato che i server restituiti al servizio potevano diventare di nuovo non reattivi una volta ricevuto il traffico.

1:59 Una macchina poteva tornare, ricevere lavoro reale e smettere di rispondere. Quell'osservazione è una prova più forte di qualsiasi teoria fiduciosa nelle risposte. Immagina lo stesso server attraverso questi stati. Non disponibile. Restituito al servizio. Prende traffico. Di nuovo non reattivo. Questo illustra il resoconto di Microsoft. Cosa innesca quell'ultima transizione rimane senza risposta. Un riavvio può produrre un miglioramento

2:18 temporaneo mentre la condizione che sconfigge il server rimane irrisolta. Il consiglio di spegnerlo e riaccenderlo inizia a richiedere gli straordinari. Gli ingegneri devono controllare cosa succede dopo che il lavoro torna. I clienti hanno bisogno che il servizio continui a funzionare per la prossima richiesta, e per la successiva. Microsoft ha limitato il traffico che raggiungeva le infrastrutture interessate in alcune località. Ha anche ricostruito un sottoinsieme di server utilizzando una configurazione precedente per

2:39 testare se sarebbero rimasti reattivi. Questi sono stati esperimenti di mitigazione segnalati. Mettere in pausa le implementazioni durante il ripristino non ci fornisce alcuna prova che un'implementazione di venerdì abbia causato l'interruzione originale.

Cosa si sapeva al momento della scadenza del rapporto?

2:48 Secondo l'aggiornamento di venerdì di Microsoft alle undici e quattro UTC, le azioni di ripristino erano terminate in alcune parti dell'Asia Pacifico. Il traffico stava gradualmente tornando, con miglioramenti nell'accesso alle cassette postali e nell'elaborazione delle email in ritardo. Alcuni utenti potrebbero ancora affrontare problemi intermittenti, e il ripristino altrove continuava. Questo è il nostro termine per la segnalazione. Microsoft ha affermato di non avere prove di attività dannose, e ha promesso un rapporto completo sull'incidente dopo la mitigazione.

3:10 Aspetterei quel rapporto prima di assegnare un cattivo. Il lavoro investigativo su Internet può darti un colpevole prima ancora che tu abbia finito di aggiornare la pagina. Per gli sviluppatori, Microsoft Graph rende la dipendenza particolarmente facile da perdere.

Perché una richiesta Graph poteva fallire?

3:20 Le sue richieste per posta, calendario e contatti di Exchange potevano andare in timeout. La tua applicazione può chiamare Graph con successo per un'operazione e fallire su un'altra. Una richiesta non correlata riuscita ti dice poco se l'operazione di mailbox di cui il tuo utente ha bisogno verrà completata. La pagina di stato aveva persino bisogno di una propria via di fuga. Microsoft ha pubblicato informazioni sull'incidente pubblicamente perché gli amministratori potrebbero non essere in grado di caricare il centro di amministrazione per leggere lo stato del servizio. Quando la dashboard per scoprire cosa è rotto dipende da cosa è rotto,

3:46 la dashboard è entrata a far parte dell'incidente. Mantieni un link di stato fuori banda disponibile. Per la normale limitazione di Graph, le linee guida di Microsoft dicono di rispettare il ritardo di ripetizione quando una richiesta riceve una risposta di troppe richieste, e di utilizzare il backoff esponenziale quando l'intestazione è assente. Quella guida gestisce la limitazione. Non diagnostica questa interruzione o promette che i tentativi ripristinano il servizio. Ora le quarantotto ore.

Cosa offre la finestra di 48 ore per la posta?

4:05 La pagina di stato estesa di Microsoft afferma di aver dato priorità all'elaborazione della coda e del backlog e di aver esteso la finestra di timeout dell'email per preservare i messaggi in ritardo. Questo dà più tempo alla posta in ritardo durante il ripristino. Imposta una finestra di timeout per la posta. Microsoft non ha dato una scadenza di quarantotto ore per la riparazione del servizio, e nessuna garanzia che ogni messaggio sarebbe arrivato. Quindi mantieni oneste le dichiarazioni di consegna. Una notifica in ritardo non è necessariamente scomparsa,

4:28 e un messaggio in coda non ha necessariamente raggiunto il suo destinatario. Per lavori sensibili al tempo, verifica l'esito tramite un canale indipendente approvato. Una finestra client è una ricevuta di consegna ottimistica quando il backend è ancora in fase di ripristino. Il che lascia molto da leggere nel rapporto sull'incidente finale. Se preferisci leggere questo piuttosto che sentirlo da me, il diff arriva nella tua casella di posta ogni mattina, gratuitamente su the daily diff dot dev, link qui sotto. Quindi il verdetto di oggi, NEEDS REVIEW.

Cosa dovrebbe dimostrare un ripristino sostenuto?

4:49 Manterrei il ripristino sotto esame perché gli stessi aggiornamenti di Microsoft hanno mostrato server restituiti che fallivano sotto traffico. Il test utile è il servizio sostenuto con un lavoro reale in arrivo. Fino al rapporto finale, la causa iniziale rimane aperta. E questo è il diff per oggi. Sono Niko di Axrisi. Fai il merge responsabilmente.

Fonti

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