Microsoft Azure DevOps, una suite di servizi per il ciclo di vita delle applicazioni, ha smesso di funzionare nella regione meridionale del Brasile per circa dieci ore mercoledì a causa di un errore di codice fondamentale.

Venerdì, Eric Mattingly, Principal Software Engineering Manager, si è scusato per l’interruzione e ha rivelato il motivo dell’interruzione: Semplice errore di battitura Che ha cancellato diciassette database di produzione.

Mattingly ha spiegato che gli ingegneri di Azure DevOps a volte acquisiscono istantanee dei database di produzione per esaminare i problemi segnalati o testare i miglioramenti delle prestazioni. Si basano su un sistema in background che viene eseguito quotidianamente ed elimina le vecchie istantanee dopo un determinato periodo di tempo.

durante gli ultimi tempi il nemico – Progetto Agile Team: gli ingegneri di Azure DevOps hanno eseguito un aggiornamento del codice, sostituendo Microsoft.Azure.Management. * Pacchetti supportati Azure.ResourceManager. *NuGet.

Il risultato è stato una grande richiesta pull di modifiche che ha sostituito le chiamate API nei vecchi pacchetti con quelle nei pacchetti più recenti. Una richiesta pull è stata scritta in modo errato: una modifica del codice che deve essere rivista e unita al progetto applicabile. E l’attività di eliminazione dell’istantanea in background ha portato all’eliminazione dell’intero server.

“Nascosto all’interno di questa richiesta pull c’era un errore di battitura nell’attività di eliminazione dello snapshot che ha sostituito una chiamata per eliminare il database SQL di Azure con una che elimina il server SQL di Azure che ospita il database”, ha affermato Mattingly.

Azure DevOps dispone di test per rilevare tali problemi, ma secondo Mattingly, il codice difettoso funziona solo in determinate condizioni e quindi non è coperto bene nei test esistenti. Queste condizioni richiedono presumibilmente un’istantanea del database sufficientemente vecchia per essere rilevata dallo script di eliminazione.

Mattingly ha detto che lo Sprint 222 è stato distribuito internamente (Ring 0) senza incidenti perché non c’erano database di snapshot. Dopo diversi giorni, le modifiche al software si sono propagate nell’ambiente client (ring 1) dell’unità di scala South Brazil (un gruppo di server per un ruolo specifico). Questo ambiente disponeva di un database snapshot sufficientemente vecchio da attivare il bug, che ha causato l’eliminazione da parte del processo in background “dell’intero Azure SQL Server e di tutti i 17 database di produzione” per l’unità di misura.

Tutti i dati sono stati recuperati, ma ci sono volute più di dieci ore. Mattingly ha detto: Ci sono diverse ragioni per questo.

Uno è che, poiché i clienti non possono ripristinare autonomamente i server SQL di Azure, gli ingegneri di Azure On-Demand hanno dovuto gestirlo, un processo che ha richiesto circa un’ora per molti utenti.

Un altro motivo è che i database hanno configurazioni di backup diverse: alcuni sono configurati per i backup dell’area e altri sono impostati per il backup più recente nell’area geografica. La risoluzione di questa discrepanza ha aggiunto molte ore al processo di ripristino.

“Finalmente, anche dopo che i database hanno iniziato a tornare online”, ha affermato Mattingly, “l’intera unità di dominio è rimasta inaccessibile anche ai clienti i cui dati erano in quei database a causa di una serie complessa di problemi con i nostri server web”.

Questi problemi derivavano da un’attività di riscaldamento del server che scorreva l’elenco dei database disponibili con una chiamata di prova. I database in fase di ripristino hanno generato un errore che ha attivato il test di riscaldamento per “eseguire un nuovo tentativo di rollback esponenziale con il risultato che il riscaldamento richiede in media novanta minuti, rispetto a meno di un secondo in condizioni normali”.

A peggiorare le cose, questo processo di ripristino è stato scaglionato e non appena uno o due dei server hanno iniziato a ricevere nuovamente il traffico del client, sarebbero stati sovraccaricati e inattivi. Alla fine, il ripristino del servizio ha richiesto il blocco di tutto il traffico verso la SBU fino a quando tutto non fosse stato sufficientemente pronto per ricongiungersi al sistema di bilanciamento del carico e gestire il traffico.

Sono state messe in atto diverse correzioni e riconfigurazioni per evitare che il problema si ripresenti.

“Ancora una volta, ci scusiamo con tutti i clienti interessati da questa interruzione”, ha affermato Mattingly. ®