Postmortem: si è verificato un errore 500 imprevisto durante l'accesso dell'utente

Sommario#

Il 18 luglio 2024, Logto Cloud ha subito un'interruzione del servizio con errore 500 del server interno dai servizi di autenticazione.

• Utenti interessati: Tutti gli utenti del Cloud che tentano di autenticarsi
• Regioni interessate: Europa e Stati Uniti
• Gravità: Critica, interrompendo l'esperienza di accesso degli utenti

Causa principale#

Durante un recente deployment di Cloud, un cambiamento radicale nello schema del database ha causato il fallimento dell'API di accesso durante la transizione tra gli ambienti di staging e produzione.

Cronologia#

• 2024-07-18 08:57 (UTC): Aggiornamenti distribuiti su Logto Cloud
• 2024-07-18 09:28 (UTC): Il primo utente ha segnalato un errore 500
• 2024-07-18 09:31 (UTC): Il team di sviluppo ha riconosciuto il problema e ha iniziato a indagare
• 2024-07-18 09:32 (UTC): Il problema è stato automaticamente risolto
• 2024-07-18 09:40 (UTC): Individuata la causa principale

Analisi dell'incidente#

Cos'è il cambiamento radicale nel database e Perché?#

Attualmente stiamo sviluppando una nuova funzione chiamata "Bring your UI", che consente agli utenti di personalizzare l'esperienza di accesso di Logto con le loro pagine web. Questa funzione richiede una nuova colonna nella tabella sign-in-exp per memorizzare la configurazione dell'interfaccia utente personalizzata.

A causa di alcuni cambiamenti nei requisiti durante lo sviluppo, il rilascio della funzione è stato ritardato, ma la prima parte della modifica dello schema è stata già distribuita in produzione alcune settimane fa, nonostante non fosse ancora in uso. Un aggiornamento della colonna del database è stato introdotto in questa PR.

Sfortunatamente, questo cambiamento non era retrocompatibile, causando il fallimento delle richieste API dal vecchio codice quando comunicavano con il nuovo database.

Come distribuiamo una nuova versione di Logto Cloud?#

Quando distribuiamo una nuova versione di Logto Cloud, la distribuiamo prima nell'ambiente di staging e poi scambiamo gli ambienti di staging e produzione. Il processo è il seguente:

1. Eseguire lo script di alterazione del database e aggiornare il database.
2. Distribuire il nuovo codice sorgente al server di staging.
3. Eseguire il server di staging e effettuare i test.
4. Scambiare i server di staging e produzione in modo che lo "staging" diventi "produzione", consentendo agli utenti di accedere alla nuova versione senza tempi di inattività.

Tuttavia, entrambi gli ambienti condividono lo stesso database e l'intero processo richiede tempo. Quindi, nella finestra temporale tra l'aggiornamento del database e lo scambio degli ambienti, gli utenti online rimangono nell'ambiente di produzione con il vecchio codice ma tentano di comunicare con il nuovo database.

Questa è stata la causa principale dell'incidente e il motivo per cui è stato automaticamente risolto in 35 minuti.

Perché questo non è stato affrontato nel processo di revisione del codice?#

Abbiamo UN task CI per verificare la retrocompatibilità delle modifiche al database. Tuttavia, in precedenza non era richiesto superare il controllo CI prima di unire la PR. Questo perché la fase di sviluppo è solitamente breve, entro pochi sprint, e la prima e la seconda parte delle modifiche allo schema sono generalmente incluse nella stessa fase di rilascio.

Questa volta, il rilascio della funzione è stato ritardato, distribuendo le modifiche allo schema su due rilasci. Lo sviluppatore ha supposto che il fallimento del CI fosse previsto e ha informato i revisori che non doveva bloccare la PR dall'unione.

C'era sicuramente un gap di comunicazione, e infine la PR è stata fusa senza fornire alcun supporto necessario per la retrocompatibilità.

Lezione appresa#

• Quando si effettua un cambiamento radicale nello schema del database, dovremmo sempre considerare la retrocompatibilità con la vecchia versione del codice sorgente.
• Quando si altera una colonna del database, dovremmo evitare di cambiarla direttamente nello schema, ma invece utilizzare l'approccio di deprecazione e migrazione.
• Lo sviluppatore dovrebbe avere maggiore consapevolezza del processo di rilascio e della timeline.

Misure correttive e preventive#

• ✅ Il controllo CI della retrocompatibilità del database è ora richiesto per superare prima di unire una PR che contiene modifiche allo schema.
• ✅ Sottolineare l'importanza della retrocompatibilità all'interno del team.