Această greșeală de tipar a cauzat o întrerupere în registrul Microsoft Azure

Microsoft Azure DevOps, o suită de servicii pentru ciclul de viață al aplicațiilor, a încetat să funcționeze în regiunea de sud a Braziliei timp de aproximativ zece ore miercuri din cauza unei erori fundamentale de cod.

Vineri, Eric Mattingly, managerul principal de inginerie software, și-a cerut scuze pentru întrerupere și a dezvăluit motivul întreruperii: Greșeală simplă Asta a șters șaptesprezece baze de date de producție.

Mattingly a explicat că inginerii Azure DevOps fac uneori instantanee ale bazelor de date de producție pentru a analiza problemele raportate sau pentru a testa îmbunătățirile de performanță. Ei se bazează pe un sistem de fundal care rulează zilnic și șterge instantaneele vechi după o anumită perioadă de timp.

în ultima vreme dusmanul – Proiect de echipă Agile – Inginerii Azure DevOps au făcut o actualizare a codului, înlocuind Microsoft.Azure.Management. * Pachete acceptate Azure.ResourceManager. * NuGet.

Rezultatul a fost o cerere pull mare pentru modificări care au înlocuit apelurile API din pachetele vechi cu cele din pachetele mai noi. O cerere de extragere a fost scrisă greșit – o modificare de cod care trebuie revizuită și îmbinată în proiectul aplicabil. Și sarcina de ștergere a instantaneului de fundal a dus la ștergerea întregului server.

„În această solicitare de extragere a fost ascunsă o greșeală de tipar în sarcina de ștergere a instantaneului care a înlocuit un apel de ștergere a bazei de date Azure SQL cu unul care șterge serverul Azure SQL care găzduiește baza de date”, a spus Mattingly.

Azure DevOps are teste pentru a detecta astfel de probleme, dar conform lui Mattingly, codul defectuos funcționează doar în anumite condiții și, prin urmare, nu este bine acoperit în testele existente. Aceste condiții necesită probabil un instantaneu al bazei de date care este suficient de vechi pentru a fi detectat de scriptul de ștergere.

Mattingly a spus că Sprint 222 a fost implementat intern (Ring 0) fără incidente, deoarece nu existau baze de date instantanee. După câteva zile, modificările software s-au propagat în mediul client (ring 1) al unității la scară South Brazil (un grup de servere pentru un anumit rol). Acest mediu avea o bază de date instantanee care era suficient de veche pentru a declanșa eroarea, ceea ce a determinat ca munca de fundal să șteargă „întregul Azure SQL Server și toate cele 17 baze de date de producție” pentru unitatea de măsură.

Toate datele au fost recuperate, dar a durat mai mult de zece ore. Mattingly a spus: Există mai multe motive pentru asta.

Una este că, deoarece clienții nu pot reînvia serverele Azure SQL ei înșiși, inginerii Azure On-Demand au trebuit să se ocupe de asta, un proces care a durat aproximativ o oră pentru mulți utilizatori.

Un alt motiv este că bazele de date au diferite configurații de backup: unele sunt configurate pentru copii de rezervă ale regiunii, iar altele sunt configurate pentru cea mai recentă copie de rezervă din regiunea geografică. Rezolvarea acestei nepotriviri a adăugat multe ore la procesul de recuperare.

„În sfârșit, chiar și după ce bazele de date au început să revină online”, a spus Mattingly, „întreaga unitate de domeniu a rămas inaccesibilă chiar și pentru clienții ale căror date se aflau în acele baze de date din cauza unui set complex de probleme cu serverele noastre web”.

Aceste probleme au apărut în urma unei sarcini de încălzire a serverului care a trecut prin lista de baze de date disponibile cu un apel de testare. Bazele de date care se aflau în curs de recuperare au scos o eroare care a declanșat testul de încălzire pentru a „efectuează o reîncercare exponențială de rollback, ceea ce a dus la încălzirea să dureze în medie nouăzeci de minute, față de mai puțin de o secundă în mod normal”.

Pentru a înrăutăți lucrurile, acest proces de recuperare a fost eșalonat și, de îndată ce unul sau două dintre servere începeau să preia din nou traficul clienților, acestea erau supraîncărcate și oprite. În cele din urmă, restabilirea serviciului a necesitat blocarea întregului trafic către SBU până când totul a fost suficient de pregătit pentru a se alătura din nou la echilibrator de încărcare și a gestiona traficul.

Au fost puse în aplicare mai multe remedieri și reconfigurari pentru a preveni reapariția problemei.

„Încă o dată, ne cerem scuze tuturor clienților afectați de această întrerupere”, a spus Mattingly. ®