Postmortem: oväntat 500-fel inträffade under användarinloggning

Sammanfattning#

Den 18 juli 2024 drabbades Logto Cloud av ett servicestopp med 500 Internt serverfel från autentiseringstjänsterna.

• Påverkade användare: Alla molnanvändare som försöker autentisera
• Påverkade regioner: Europa och USA
• Allvarlighetsgrad: Kritisk, stör användarinloggningen

Grundorsak#

Under en nyligen genomförd molndistribution orsakade en brytande ändring i databasschemat att API:et för inloggningsupplevelse misslyckades under övergången mellan staging- och produktionsmiljöer.

Tidslinje#

• 2024-07-18 08:57 (UTC): Uppdateringar distribuerades till Logto Cloud
• 2024-07-18 09:28 (UTC): Första användaren rapporterade ett 500-fel
• 2024-07-18 09:31 (UTC): Utvecklingsteamet erkände problemet och började undersöka
• 2024-07-18 09:32 (UTC): Problemet löstes automatiskt
• 2024-07-18 09:40 (UTC): Grundorsaken identifierad

Incidentanalys#

Vad är den brytande ändringen i databasen och varför?#

Vi utvecklar för närvarande en ny funktion som kallas "Bring your UI", som tillåter användare att anpassa Logtos inloggningsupplevelse med sina egna webbsidor. Denna funktion kräver en ny kolumn i tabellen sign-in-exp för att lagra den anpassade UI-konfigurationen.

På grund av vissa kravändringar under utvecklingen blev funktionslanseringen försenad, men den första delen av schemaändringen distribuerades redan till produktionen för flera veckor sedan, trots att den ännu inte används. En uppdatering av databasens kolumn introducerades i detta PR.

Tyvärr var denna ändring inte bakåtkompatibel, vilket orsakade att API-förfrågningar från den gamla koden misslyckades när de kommunicerade med den nya databasen.

Hur distribuerar vi en ny version av Logto Cloud?#

När vi distribuerar en ny version av Logto Cloud, distribuerar vi den först till staging-miljön och byter sedan staging- och produktionsmiljöerna. Processen är som följer:

1. Kör databasändringsskript och uppdatera databasen.
2. Distribuera den nya källkoden till staging-servern.
3. Kör staging-server och utför tester.
4. Byt staging- och produktionsservrar så att "staging" blir "produktion", vilket tillåter användare att få tillgång till den nya versionen utan driftstopp.

Emellertid delar båda miljöerna samma databas, och hela processen tar tid. Så i tidsfönstret mellan databasuppdateringen och miljöbytet, förblir onlineanvändare i produktionsmiljön med den gamla koden men försöker kommunicera med den nya databasen.

Detta var grundorsaken till incidenten och orsaken till att den automatiskt löstes på 35 minuter.

Varför åtgärdades detta inte under kodgranskningsprocessen?#

Vi har en CI-uppgift för att kontrollera bakåtkompatibiliteten för databasändringarna. Tidigare var det dock inte nödvändigt att klara CI-kontrollen innan sammanslagningen av PR. Detta beror på att utvecklingsfasen för det mesta är kort inom några sprinter, och den första och andra delen av schemaändringarna vanligtvis ingår i samma lanseringsfas.

Den här gången blev funktionslanseringen försenad och spred schemaändringarna över två lanseringar. Utvecklaren antog att CI-felet var förväntat och informerade granskarna om att det inte borde blockera PR från att slås samman.

Ett kommunikationsgap fanns definitivt också där, och slutligen slogs PR samman utan att ge nödvändigt bakåtkompatibilitetsstöd.

Lärdomar#

• När man gör en brytande ändring i databasschema, bör vi alltid överväga bakåtkompatibilitet med den gamla versionen av källkoden.
• När vi ändrar en databas kolumn, bör vi undvika att ändra den direkt i schemat, utan istället använda en avvecklings- och migreringsmetod.
• Utvecklaren bör ha större medvetenhet om lanseringsprocessen och tidslinjen.

Korrigerande och förebyggande åtgärder#

• ✅ Bakåtkompatibilitetskollen för databasen är nu obligatorisk att klara innan man slår samman en PR som innehåller schemaändring.
• ✅ Betona vikten av bakåtkompatibilitet inom teamet.