Afgelopen woensdag ging een stuk van de Azure cloud in Brazilië meer dan tien uur lang onderuit. In een blogpost legt een ingenieur van Microsoft uit hoe een klein foutje grote gevolgen had.
Het gaat om Azure DevOps dat gedurende 10,5 uur plat lag in de South Brazil regio (SBR). Principal software engineering manager Eric Mattingly legt uit dat dat gebeurde door een upgrade van de codebasis. Concreet werden de verouderde Microsoft.Azure.Managment.* packages vervangen door de Azure.ResourceManager.* NuGet packages.
Dat ging gepaard met een aantal handmatige aanpassingen, waarbij in één van de verzoeken een tikfout zat in de opdracht voor het verwijderen van de snapshots (een soort digitale foto van de toestand op een bepaald moment van een database). Normaal moest de Azure SQL Database worden verwijderd, maar in plaats daarvan werd de Azure SQL Server waar de database draait verwijderd.
Microsoft geeft toe dat dat een zeldzame gebeurtenis is waarop onvoldoende werd getest. Zo werd de nieuwe code eerst uitgerold op ‘Ring 0’, de interne Azure DevOps organisatie, waar er geen snapshot databases waren en dus niets werd uitgevoerd. Na enkele dagen werd ook Ring 1 (waaronder de Zuid-Braziliaanse regio zat) geupgrade waar wel een snapshot database zat die oud genoeg was om de bug in gang te zetten en de Azure SQL server werd verwijderd. Ook alle 17 productie databases werden daarbij verwijderd waar geen klantendata kon verwerkt worden. Er was wel geen verlies van klantendata zegt Microsoft.
Snel opgemerkt, lang herstel
Microsoft benadrukt dat het binnen de twintig minuten de problemen had opgemerkt en dat het probleem ook snel duidelijk was. Maar waarom duurde het dan nog tien uur? Door meerdere complexiteiten. Zo duurde het een uur voor het Azure SQL team de server kon herstellen.
Vervolgens duurde het meerdere uren bij het herstel omdat databases moesten worden gekopieerd naar een gekoppelde regio. Tot slot bleef het ook nadien lastig toegankelijk voor klanten door een reeks complexe technische problemen, zo gebeurt er bij bepaalde processen een taak die alle databases oplijst en connecteert. Maar tijdens het herstel gaf dat problemen waardoor dat proces, dat normaal geen seconde duurt, tot negentig minuten duurde. Die dingen gecombineerd maakten dat de dienst ruim tien uur lang onbeschikbaar was.
Fout opgemerkt of meer nieuws? Meld het hier