Il codice mal configurato ha causato l'interruzione di Azure del 18 novembre - Microsoft

Table Of Contents

• Microsoft afferma che l’interruzione di Azure del 18 novembre è dovuta a codice mal configurato
• Protocollo di annullamento
• La dichiarazione

Microsoft afferma che l’interruzione di Azure del 18 novembre è dovuta a codice mal configurato

Microsoft Azure, la sua piattaforma cloud per le aziende, ha subito un’interruzione importante il 18 novembre che ha lasciato molti utenti in difficoltà. In una dichiarazione, Microsoft ha affermato che l’interruzione è stata causata dai suoi sviluppatori che hanno implementato codice errato.

Protocollo di annullamento

Sembra che gli sviluppatori di Microsoft stessero lavorando per risolvere un bug nel loro software. La soluzione al bug, apparentemente, ha causato l’enorme interruzione dei servizi cloud di Azure. Microsoft ha dichiarato di aver testato l’aggiornamento prima di implementarlo. Ma non è sempre possibile prevedere con precisione il risultato di un aggiornamento software su una piattaforma così grande in un ambiente di test controllato. Pertanto, Microsoft segue una politica di distribuzione di qualsiasi nuovo aggiornamento sezione per sezione, qualcosa che chiamano flighting, ovvero limitare il rollout. Questa volta, però, probabilmente a causa di un’eccessiva impazienza, gli sviluppatori hanno distribuito l’intero pacchetto di aggiornamento tutto in una volta, il che ha causato un effetto a cascata su tutti i suoi server. In una dichiarazione rilasciata sul blog di Azure, Jazon Zander, CVP, Azure Team, ha notato che,

Di conseguenza, i tassi di connessione ad Azure il 18 novembre sono scesi dal 97% al 7%-8% dopo le 19:00 ora orientale in Virginia del Nord. Il data center di Azure a Dallas ha subito un’interruzione completa per un breve periodo. I data center in Europa non si sono ripresi fino a tarda mattinata del giorno successivo.

Ha aggiunto ulteriormente che, sebbene abbiano una politica di distribuzione standard per l’aggiornamento/patching dei bug, ci sono state comunicazioni apparenti, “La politica standard di distribuzione flighting di implementare gradualmente le modifiche su piccole porzioni non è stata seguita,” ha scritto Zander. Zander ha affermato che il loro team aveva identificato il problema principale, che era un problema di configurazione negli front-end di Azure Table storage. “L’interruttore di configurazione è stato attivato in modo errato per gli front-end di Azure Blob storage,” ha scritto Zander.

Gli front-end di Table storage registrano la sequenza dei diversi tipi di dati che vanno in un Blob (un servizio per memorizzare grandi quantità di dati non strutturati) e possono essere utilizzati per guidare il recupero dei dati. L’errore nell’interruttore di configurazione sembra aver causato un ciclo infinito che ha portato infine all’interruzione del servizio cloud di Azure.

La dichiarazione

L’aggiornamento originale doveva correggere alcuni bug scoperti dal team di Azure e migliorare le prestazioni della piattaforma cloud. L’aggiornamento si è dimostrato efficace in ogni test nella fase di test alpha. I risultati positivi dei test alpha probabilmente hanno esaltato gli sviluppatori a rinunciare al metodo di distribuzione flighting e hanno implementato l’aggiornamento tutto in una volta. Il risultato, come visto il 18 novembre, è stata un’interruzione totale che ha causato problemi agli utenti. In risposta, gli amministratori di Azure hanno ora implementato una pratica di aggiornamento automatizzato, che non permetterà che un evento del genere si verifichi di nuovo.

In forse il risultato più chiaro dell’incidente, Zander ha scritto: “Microsoft Azure aveva linee guida operative chiare, ma c’era una lacuna negli strumenti di distribuzione che si basavano su decisioni umane … Con gli aggiornamenti degli strumenti, la politica è ora applicata dalla piattaforma di distribuzione stessa.”

Zander ha riconosciuto che le operazioni cloud devono diventare più affidabili e ha affermato che Microsoft continuerà a lavorare su questo obiettivo. “Ci scusiamo sinceramente e riconosciamo l’impatto significativo che questa interruzione del servizio potrebbe aver avuto sulle vostre applicazioni e servizi,” ha scritto.

Zander potrebbe essersi scusato sinceramente per l’eccesso di entusiasmo del suo team di sviluppo, ma il fatto rimane che Microsoft sta spingendo patch e aggiornamenti in fretta senza i necessari test. Questo problema ha già portato Microsoft a rilasciare patch/aggiornamenti difettosi che causano BSOD, nei suoi aggiornamenti di Patch Tuesday due volte, una volta a ottobre con KB 2949927 e a dicembre con KB 3004394, solo per rimuoverli successivamente. Gli utenti sperano che Microsoft esca con una SOP per rilasciare solo quegli aggiornamenti/pacchetti che sono stati verificati in un ambiente di lavoro reale.