Jälkitutkinta: Odottamaton 500-virhe ilmeni käyttäjän kirjautumisen aikana

Yhteenveto#

18. heinäkuuta 2024 Logto Cloud koki palvelukatkon, jossa todennuspalveluista aiheutui 500 Sisäinen palvelinvirhe.

• Vaikuttaneet käyttäjät: Kaikki Cloud-käyttäjät, jotka yrittivät todentaa
• Vaikuttaneet alueet: Eurooppa ja Yhdysvallat
• Vakavuus: Kriittinen, häiriten käyttäjien kirjautumiskokemusta

Juurisyy#

Viimeisimmässä Cloud-jakelussa tietokannan skeeman rikkova muutos aiheutti kirjautumiskokemus-API:n epäonnistumisen siirtymävaiheessa kehityksestä tuotantoympäristöön.

Aikajana#

• 2024-07-18 08:57 (UTC): Päivitykset otettu käyttöön Logto Cloudissa
• 2024-07-18 09:28 (UTC): Ensimmäinen käyttäjä ilmoitti 500-virheestä
• 2024-07-18 09:31 (UTC): Kehitystiimi tunnisti ongelman ja aloitti tutkimisen
• 2024-07-18 09:32 (UTC): Ongelma ratkesi automaattisesti
• 2024-07-18 09:40 (UTC): Juurisyy tunnistettiin

Tapauksen analyysi#

Mikä on tietokannan rikkova muutos ja miksi?#

Kehitämme parhaillaan uutta ominaisuutta nimeltä "Tuo oma käyttöliittymäsi", jonka avulla käyttäjät voivat mukauttaa Logto-kirjautumiskokemusta omilla verkkosivuillaan. Tämä ominaisuus vaatii uuden sarakkeen sign-in-exp-tauluun mukautetun käyttöliittymän konfiguraation tallentamiseksi.

Kehityksen aikana tapahtuneiden vaatimusten muutosten vuoksi ominaisuuden julkaisu viivästyi, mutta ensimmäinen osa skeemamuutoksesta oli jo otettu käyttöön tuotannossa useita viikkoja sitten, vaikka se ei vielä ollut käytössä. Päivitys tietokannan sarakkeeseen esitettiin tässä PR:ssä.

Valitettavasti tämä muutos ei ollut taaksepäin yhteensopiva, mikä aiheutti, että API-pyynnöt vanhasta koodista epäonnistuivat, kun ne kommunikoivat uuden tietokannan kanssa.

Kuinka otamme käyttöön uuden Logto Cloud -version?#

Kun otamme käyttöön uuden version Logto Cloudista, otamme sen ensin käyttöön kehitysympäristössä ja vaihdamme sitten kehitys- ja tuotantoympäristöt. Prosessi on seuraava:

1. Suorita tietokannan muutosskripti ja päivitä tietokanta.
2. Ota uusi lähdekoodi käyttöön kehityspalvelimelle.
3. Käynnistä kehityspalvelin ja suorita testit.
4. Vaihda kehitys- ja tuotantoympäristöt niin, että "kehitys" muuttuu "tuotannoksi", jolloin käyttäjät pääsevät uuteen versioon ilman katkoksia.

Kuitenkin molemmat ympäristöt jakavat saman tietokannan, ja koko prosessi vie aikaa. Niinpä aikajanalla tietokannan päivityksen ja ympäristön vaihdon välillä online-käyttäjät pysyvät tuotantoympäristössä vanhan koodin kanssa, mutta yrittävät kommunikoida uuden tietokannan kanssa.

Tämä oli tapauksen juurisyy ja syy, miksi se ratkesi automaattisesti 35 minuutissa.

Miksi tätä ei käsitelty koodin tarkistusprosessissa?#

Meillä ON CI-tehtävä, joka tarkistaa tietokannan muutosten taaksepäin yhteensopivuuden. Aiemmin ei kuitenkaan ollut vaatimusta läpäistä CI-tarkistus ennen PR:n yhdistämistä. Tämä johtuu siitä, että suurimman osan ajasta kehitysvaihe on yleensä lyhyt muutaman sprintin sisällä, ja ensimmäiset ja toiset skeemamuutokset sisältyvät yleensä samaan julkaisuvaiheeseen.

Tällä kertaa ominaisuuden julkaisu viivästyi, levittäen skeemamuutokset kahteen julkaisuvaiheeseen. Kehittäjä oletti, että CI-virhe oli odotettu ja ilmoitti tarkistajille, että sen ei pitäisi estää PR:n yhdistämistä.

Viestintäkuilu oli ehdottomasti olemassa, ja lopulta PR yhdistettiin ilman tarpeellista taaksepäin yhteensopivuustukea.

Opitut asiat#

• Kun teemme rikkovan muutoksen tietokannan skeemassa, meidän tulisi aina ottaa huomioon taaksepäin yhteensopivuus vanhan lähdekoodin version kanssa.
• Kun muutamme tietokannan saraketta, meidän tulisi välttää sen muuttamista skeemassa suoraan, vaan käyttää poistumisen ja migraation lähestymistapaa.
• Kehittäjän tulisi olla tietoisempi julkaisuprosessista ja aikataulusta.

Korjaavat ja ehkäisevät toimenpiteet#

• ✅ Tietokannan taaksepäin yhteensopivuuden CI-tarkistus on nyt vaadittava ennen PR:n yhdistämistä, joka sisältää skeemamuutoksen.
• ✅ Korosta taaksepäin yhteensopivuuden tärkeyttä tiimin sisällä.