Postmortem: onverwachte 500 fout opgetreden tijdens gebruikersaanmelding

Samenvatting#

Op 18 juli 2024 ondervond Logto Cloud een dienstonderbreking met een 500 Interne serverfout van de authenticatiediensten.

• Getroffen gebruikers: Alle Cloud-gebruikers die probeerden te authenticeren
• Getroffen regio's: Europa en VS
• Ernst: Kritiek, verstoring van de gebruikersaanmeldingservaring

Oorzaak#

Tijdens een recente Cloud-implementatie veroorzaakte een ingrijpende wijziging in het databaseschema dat de API voor de aanmeldingservaring faalde tijdens de overgang tussen de staging- en productieomgevingen.

Tijdlijn#

• 2024-07-18 08:57 (UTC): Updates geïmplementeerd in Logto Cloud
• 2024-07-18 09:28 (UTC): Eerste gebruiker meldde een 500 fout
• 2024-07-18 09:31 (UTC): Dev-team erkende het probleem en begon met het onderzoek
• 2024-07-18 09:32 (UTC): Het probleem werd automatisch opgelost
• 2024-07-18 09:40 (UTC): Oorzaak geïdentificeerd

Incidentanalyse#

Wat is de ingrijpende wijziging in de database en Waarom?#

We ontwikkelen momenteel een nieuwe functie genaamd "Breng je UI", waarmee gebruikers de Logto-aanmeldingservaring kunnen aanpassen met hun eigen webpagina's. Deze functie vereist een nieuwe kolom in de sign-in-exp tabel om de aangepaste UI-configuratie op te slaan.

Vanwege enkele wijzigende vereisten tijdens de ontwikkeling werd de functie-release vertraagd, maar het eerste deel van de schemawijziging werd al enkele weken geleden naar de productie gebracht, hoewel het nog niet in gebruik was. Een update van de databasekolom werd geïntroduceerd in deze PR.

Helaas was deze wijziging niet achterwaarts compatibel, waardoor API-verzoeken van de oude code faalden bij communicatie met de nieuwe database.

Hoe implementeren we een nieuwe versie van Logto Cloud?#

Bij het implementeren van een nieuwe versie van Logto Cloud implementeren we deze eerst naar de staging-omgeving en wisselen vervolgens de staging- en productieomgevingen. Het proces is als volgt:

1. Voer het database-alteratiescript uit en werk de database bij.
2. Implementeer de nieuwe broncode naar de staging-server.
3. Voer de staging-server uit en voer tests uit.
4. Wissel de staging- en productie-servers, zodat de "staging" "productie" wordt, waardoor gebruikers toegang hebben tot de nieuwe versie zonder downtime.

Echter, beide omgevingen delen dezelfde database, en het hele proces neemt tijd in beslag. Dus in het tijdsvenster tussen de database-update en het wisselen van omgevingen blijven online gebruikers in de productieomgeving met de oude code maar proberen te communiceren met de nieuwe database.

Dit was de oorzaak van het incident en de reden waarom het automatisch werd opgelost in 35 minuten.

Waarom werd dit niet aangepakt in het codebeoordelingsproces?#

We hebben WEL een CI-taak om de achterwaartse compatibiliteit van de databasewijzigingen te controleren. Echter, eerder was het niet verplicht om de CI-controle te halen voordat de PR werd samengevoegd. Dit komt omdat de ontwikkelingsfase meestal kort is binnen enkele sprints, en het eerste en tweede deel van de schemawijzigingen meestal worden opgenomen in dezelfde releasefase.

Deze keer werd de functie-release vertraagd, waardoor de schemawijzigingen over twee releases werden verspreid. De ontwikkelaar ging ervan uit dat de CI-fout werd verwacht en informeerde de beoordelaars dat het de PR niet zou moeten blokkeren voor samenvoeging.

Er was zeker een communicatiekloof aanwezig en uiteindelijk werd de PR samengevoegd zonder de benodigde achterwaartse compatibiliteitsondersteuning te bieden.

Les geleerd#

• Bij het maken van een ingrijpende wijziging in het databaseschema moeten we altijd rekening houden met de achterwaartse compatibiliteit met de oude versie van de broncode.
• Bij het wijzigen van een databasekolom moeten we vermijden deze direct in het schema te wijzigen, maar in plaats daarvan de uitfaserings- en migratieaanpak gebruiken.
• De ontwikkelaar moet meer bewustzijn hebben van het releaseproces en de tijdlijn.

Corrigerende en preventieve maatregelen#

• ✅ De CI-controle voor de achterwaartse compatibiliteit van de database is nu verplicht om te slagen voordat een PR die schemawijzigingen bevat wordt samengevoegd.
• ✅ Benadruk het belang van achterwaartse compatibiliteit binnen het team.