Il giorno dopo l’interruzione di Microsoft 365: cosa abbiamo imparato e cosa puoi fare adesso

Giovedì 12 novembre 2026 Exchange Online, Teams, SharePoint Online, Microsoft 365 Copilot e Defender XDR sono andati giù o hanno funzionato a rilento in tutto il mondo. Questo articolo mette ordine: cosa è documentato, cosa resta aperto, cosa impariamo e cosa puoi fare oggi senza rifare tutta l’infrastruttura.

Il tema di quanto si voglia dipendere da un solo fornitore è trattato in Interruzione di Microsoft 365 e dipendenza. Qui si parla dell’analisi e dei passi concreti dopo.

Stato delle informazioni: Microsoft non ha ancora pubblicato una relazione finale (post-incident review). Quanto segue si basa sugli aggiornamenti di stato di Microsoft riassunti da BleepingComputer e su un’analisi tecnica di Control Plane. L’analisi è un’interpretazione, non una conferma di Microsoft.

Cosa è accertato

• Inizio: l’incidente principale (ID nel centro di amministrazione MO1550821) è iniziato il 12 novembre alle 18:26 UTC con problemi a Exchange Online nelle Americhe, poi si è esteso ad altre regioni e ai servizi dipendenti. Un incidente più breve di Teams (TM1550488) c’era stato lo stesso giorno tra le 14:45 e le 15:53 UTC; Microsoft non ha detto se i due siano collegati.
• Causa secondo Microsoft: prima carico elevato, poi vari server diventati inaspettatamente non disponibili che sovraccaricavano gli altri, infine un processo centrale dei server colpiti andato in sovraccarico. Il traffico non sarebbe aumentato. Cosa abbia innescato i primi guasti non è stato pubblicato.
• Nessun attacco: Microsoft non vede segnali di attività malevola.
• Misure: distribuzioni sospese, traffico reindirizzato, server riavviati, metodo dei controlli di salute cambiato, alcune modifiche di configurazione recenti valutate per il ripristino e finestra di consegna della posta estesa a 48 ore.
• Ripresa: il 13 novembre Microsoft ha segnalato miglioramenti in Nordamerica e gran parte dell’Europa e, nel pomeriggio, code di posta molto più corte. Notizie del 14 novembre parlano di servizi ripristinati; mancano ancora la chiusura ufficiale e il rapporto sulla causa.

Cosa suggerisce l’analisi (non confermato)

La descrizione corrisponde a uno schema noto, il guasto a cascata: i controlli di salute tolgono dal servizio i server malati, il loro carico finisce sugli altri, che a loro volta non superano i controlli. Il carico per server continua a salire anche se il traffico resta uguale. I server rimessi in servizio sarebbero caduti di nuovo sotto carico. Questo spiega perché il ripristino è durato ore e non minuti. Non spiega cosa abbia causato il primo guasto; è la domanda per il rapporto finale.

Cosa impariamo

1. Un fornitore, un raggio d’azione enorme. Posta, chat, file, calendario e Defender XDR stavano sullo stesso filo. Se rilevi gli incidenti con Defender e ne parli su Teams, nelle prime ore eri cieco e muto insieme.
2. Gli allarmi via posta dallo stesso fornitore non sono allarmi. Se il fornitore cade, non arriva nemmeno l’avviso.
3. I messaggi di stato sono cambiati. Da «carico elevato» a «server non disponibili» a «processo centrale sovraccarico». È normale durante la ricerca del guasto, ma significa: non girare le prime valutazioni come verità finale.
4. La ripresa ha una lunga coda. Anche dopo «funziona di nuovo» le code si svuotano e la posta arriva in ritardo.
5. Le voci arrivano subito. In ogni grande interruzione compare «attacco hacker». Aspetta la dichiarazione del fornitore e riferisci al team solo il documentato.

Dieci misure per oggi

1. Scopri cosa si è perso. Controlla la coda di posta e i messaggi di rimbalzo del tuo gateway per i messaggi del 12 e 13 novembre non arrivati. Chiedi ai mittenti importanti.
2. Definisci un canale di comunicazione fuori da Microsoft. Un albero telefonico, un messenger o una pagina di emergenza su un’altra infrastruttura. Scrivi chi lo attiva e chi lo annuncia.
3. Crea due account admin di emergenza (account cloud, separati da quelli normali, molto protetti e controllati). Microsoft li descrive come account di accesso di emergenza.
4. Fai passare gli allarmi da una seconda via. Un monitoraggio che ti scrive via posta ha bisogno anche di SMS, push o di un altro fornitore di posta.
5. Monitora dall’esterno. Un piccolo test che invia regolarmente una mail alla tua casella e verifica l’arrivo ti mostra un’interruzione prima dei colleghi. Iscriviti anche al feed dello stato dei servizi.
6. Conosci la tua configurazione MX e DNS. Quali sono i TTL, chi gestisce la zona, cosa succede alla posta in ingresso se il fornitore della casella tace per 48 ore? Il controllo DNS della posta mostra MX, SPF, DKIM e DMARC di un dominio in un solo passaggio. Non cambiare i record MX in preda al panico durante un’interruzione: pianifica la soluzione prima.
7. Mappa ciò che dipende dalla posta. Reimpostazione password, codici a due fattori via mail, invio fatture, sistema di ticket, moduli. Scrivi l’elenco e decidi cosa richiede una seconda via.
8. Esercitati per 15 minuti. Simula: posta e Teams non ci sono, come raggiungi clienti e team? Correggi subito le lacune.
9. Documenta il danno e leggi il contratto. Durata, processi colpiti, costi. Verifica se valgono i crediti del livello di servizio e entro quando vanno richiesti.
10. Decidi consapevolmente cosa tenere separato. Non tutto deve lasciare Microsoft. Ma per poche cose critiche (comunicazione di emergenza, allarmi, recupero delle credenziali) vale la pena un secondo fornitore o un servizio proprio, per esempio una stanza di chat su un Nextcloud Talk gestito da te. È un’aggiunta, non una sostituzione, e richiede cura propria.

Cosa evitare

• Non allentare le impostazioni di sicurezza per «tornare a lavorare prima».
• Non fare modifiche di massa a DNS o account nel mezzo dell’interruzione.
• Non riferire ai clienti ipotesi sulla causa.

Quando Microsoft pubblicherà il rapporto finale aggiornerò questo articolo. Fino ad allora: l’interruzione è stata un test che non avevi pianificato. Usane il risultato.