Microsoft 365, problemi alla ricerca: cause, impatto e soluzione dell’incidente MO1456424

Gli aggiornamenti pubblici non chiariscono quale percorso del codice fosse coinvolto, quale tipo di risorsa avesse raggiunto i limiti o quale modifica precisa fosse stata introdotta dal deployment. L’evidenza disponibile consente quindi di parlare di un problema legato a una distribuzione software recente e all’efficienza delle risorse, non di un attacco informatico, di un guasto di rete regionale confermato o di una crisi di capacità dell’intera piattaforma.

La soluzione sviluppata da Microsoft

Microsoft ha dichiarato di aver preparato e iniziato a distribuire una correzione con l’obiettivo di ridurre la pressione sulle risorse e ripristinare la funzionalità di ricerca. Altri resoconti hanno descritto l’intervento come una correzione distribuita per risolvere l’inefficienza e riportare i servizi interessati al normale funzionamento.

Il registro disponibile non riportava però un orario di conclusione. Non è quindi possibile stabilire da quel documento quando la correzione sia stata completata per ogni utente coinvolto. Le informazioni fornite non descrivono neppure un rollback, una modifica architetturale permanente o un intervento tecnico più dettagliato.

Perché Microsoft lo ha definito un incidente?

Nel materiale relativo allo stato dei servizi Microsoft 365, MO1456424 è indicato come evento serviceDegradation, cioè una degradazione del servizio. Non si trattava dunque della completa indisponibilità dell’intera suite Microsoft 365.

L’episodio è stato comunque registrato come incidente perché una funzione direttamente utilizzata dai clienti — la ricerca — risultava compromessa per una parte degli utenti e in più prodotti. Microsoft non ha pubblicato una spiegazione separata dei criteri con cui ha scelto questa classificazione. La lettura più prudente è quindi quella letterale: si è trattato di un degrado della ricerca su più servizi, non della caduta di ogni componente di Microsoft 365.

Un problema da non confondere con l’outage di GitHub

La coincidenza temporale può portare a collegare MO1456424 ad altri problemi dei servizi Microsoft e Microsoft-owned, ma le cause riportate sono diverse.

GitHub: 7 ore e 47 minuti di disservizi

GitHub ha affrontato un incidente separato il 17 agosto 2026, dalle 13:28 alle 21:15 UTC, per una durata di 7 ore e 47 minuti. Il suo registro di stato ha segnalato errori e latenza elevati su Issues, pull request, API, Actions e Copilot. Al picco, gli errori sul sito e sulle API hanno raggiunto circa il 20%, mentre i download di archivi e contenuti grezzi hanno toccato circa il 50%.

Secondo il resoconto pubblicato, l’evento è stato ricondotto alla saturazione dei bilanciatori di carico, a una policy di autoscaling difettosa e a un bug latente nei meccanismi di retry di Visual Studio Code. Si tratta di meccanismi differenti dal problema di efficienza introdotto dal deployment nell’infrastruttura di ricerca di MO1456424.

I precedenti problemi di ricerca in Microsoft 365

Microsoft 365 aveva già registrato incidenti legati alla ricerca. Nell’aprile 2025, gli utenti di Outlook sul web e SharePoint Online avevano riscontrato ritardi o errori collegati a componenti dell’infrastruttura che elaboravano le richieste di ricerca al di sotto delle soglie di prestazione considerate accettabili.

Altri resoconti hanno descritto anche problemi nella ricerca dei file di OneDrive: in alcuni casi le ricerche apparivano vuote o non restituivano risultati per file che gli utenti sapevano di aver caricato. Il materiale disponibile non dimostra però che questi episodi precedenti avessero la stessa causa di MO1456424.

Il guasto Azure del 23 luglio era più ampio e diverso

Anche l’evento del 23 luglio 2026 appartiene a una categoria tecnica differente. Secondo lo storico di stato di Azure, tra le 14:44 e le 19:41 UTC una parte dei clienti ha subito problemi di connettività, maggiore latenza o difficoltà nell’accesso ai servizi ospitati nella regione West US. L’impatto riguardava il traffico in entrata o in uscita dalla regione; il traffico che rimaneva interamente al suo interno non era coinvolto.

Microsoft ha attribuito il disservizio a un problema nel sistema automatizzato di manutenzione della rete, che aveva rimosso indirizzi e percorsi IP da un numero di dispositivi superiore a quello previsto. Si trattava quindi di un guasto al control plane della rete, non di un degrado del servizio di ricerca come quello registrato con MO1456424.

Che cosa mostrano, nel complesso, questi incidenti

I tre casi evidenziano rischi operativi collocati su livelli differenti:

• MO1456424: un deployment recente ha causato un uso inefficiente delle risorse nell’infrastruttura di ricerca.
• L’incidente GitHub del 17 agosto: saturazione dei bilanciatori di carico, errore nell’autoscaling e amplificazione dei tentativi di ritrasmissione.
• Il guasto Azure di luglio: un processo automatizzato di manutenzione ha rimosso troppi percorsi IP.

Il quadro è quindi quello di problemi distribuiti tra deployment applicativi, capacità e autoscaling e automazione della rete. Non è però una prova dell’esistenza di un’unica causa comune.

Le informazioni disponibili non dimostrano nemmeno che la domanda legata all’intelligenza artificiale abbia provocato MO1456424, l’incidente di GitHub o il guasto Azure di luglio. GitHub ha parlato della migrazione dai propri data center verso il cloud pubblico e di un percorso verso una strategia multicloud, ma queste scelte strategiche non stabiliscono da sole un rapporto causale con uno specifico outage.

La lezione più solida è più circoscritta: mentre i servizi cloud e i carichi di lavoro collegati all’IA diventano sempre più importanti, assumono un peso crescente la pianificazione della capacità, i controlli sui deployment, la protezione dai retry storm, l’isolamento dei guasti e l’automazione di rete adeguatamente testata. Il multicloud può distribuire una parte dei rischi infrastrutturali, ma non impedisce automaticamente un guasto all’interno del control plane di un singolo servizio.