Raport dotyczący incydentu z niespodziewanym błędem 500 zwróconym przez usługi uwierzytelniania w dniu 18 lipca 2024 r.
W dniu 18 lipca 2024 roku Logto Cloud doświadczyło przestoju usługi z błędem 500 Internal server error w usługach uwierzytelniania.
Podczas ostatniego wdrożenia Cloud, zmiana w schemacie bazy danych spowodowała awarię API doświadczenia logowania podczas przejścia między środowiskami staging a produkcyjnym.
Obecnie opracowujemy nową funkcję o nazwie "Bring your UI", która pozwala użytkownikom dostosować doświadczenie logowania Logto za pomocą ich własnych stron internetowych. Ta funkcja wymaga nowej kolumny w tabeli sign-in-exp do przechowywania konfiguracji niestandardowego UI.
Z powodu pewnych zmian wymagań podczas opracowywania, wydanie funkcji zostało opóźnione, ale pierwsza część zmiany schematu została już wdrożona do produkcji kilka tygodni temu, mimo że nie była jeszcze używana. Aktualizacja kolumny bazy danych została wprowadzona w tym PR.
Niestety, ta zmiana nie była kompatybilna wstecz, co spowodowało awarię żądań API ze starego kodu podczas komunikacji z nową bazą danych.
Podczas wdrażania nowej wersji Logto Cloud, najpierw wdrażamy ją do środowiska staging, a następnie zamieniamy środowiska staging i produkcyjne. Proces przebiega następująco:
Jednak oba środowiska korzystają z tej samej bazy danych, a cały proces zajmuje czas. Tak więc, w oknie czasowym między aktualizacją bazy danych a zamianą środowisk, użytkownicy online pozostają w środowisku produkcyjnym z starym kodem, ale próbują komunikować się z nową bazą danych.
To była przyczyna źródłowa incydentu i powód, dla którego został on automatycznie rozwiązany w ciągu 35 minut.
Mamy zadanie CI sprawdzające zgodność wsteczną zmian w bazie danych. Jednak wcześniej nie było wymagane przejście kontroli CI przed scaleniem PR. Wynika to z tego, że zazwyczaj faza opracowywania jest krótka i trwa kilka sprintów, a pierwsza i druga część zmian w schemacie są zazwyczaj uwzględniane w tej samej fazie wydania.
Tym razem, wydanie funkcji zostało opóźnione, co rozłożyło zmiany w schemacie na dwie wersje. Programista zakładał, że niepowodzenie CI było spodziewane i poinformował recenzentów, że nie powinno to blokować scalania PR.
Na pewno wystąpiła luka komunikacyjna, a ostatecznie PR został scalony bez zapewnienia niezbędnej zgodności wstecznej.