Postmortem: wystąpił nieoczekiwany błąd 500 podczas logowania użytkownika

Podsumowanie#

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.

• Dotrknięci użytkownicy: Wszyscy użytkownicy Cloud próbujący się uwierzytelnić
• Dotknięte regiony: Europa i USA
• Ważność: Krytyczna, zakłócenie doświadczenia logowania użytkowników

Przyczyna źródłowa#

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.

Linia czasu#

• 2024-07-18 08:57 (UTC): Aktualizacje wdrożone do Logto Cloud
• 2024-07-18 09:28 (UTC): Pierwszy użytkownik zgłosił błąd 500
• 2024-07-18 09:31 (UTC): Zespół programistyczny uznał problem i rozpoczął dochodzenie
• 2024-07-18 09:32 (UTC): Problem został automatycznie rozwiązany
• 2024-07-18 09:40 (UTC): Zidentyfikowana przyczyna źródłowa

Analiza incydentu#

Co to jest zmiana łamiąca w bazie danych i dlaczego?#

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.

Jak wdrażamy nową wersję Logto Cloud?#

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:

1. Uruchom skrypt zmiany bazy danych i zaktualizuj bazę danych.
2. Wdróż nowy kod źródłowy na serwer staging.
3. Uruchom serwer staging i przeprowadź testy.
4. Zamień serwery staging i produkcyjne, aby "staging" stało się "produkcyjnym", umożliwiając użytkownikom dostęp do nowej wersji bez przestojów.

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.

Dlaczego to nie zostało uwzględnione w procesie przeglądu kodu?#

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.

Nabyte lekcje#

• Podczas wprowadzania łamiącej zmiany w schemacie bazy danych, zawsze powinniśmy uwzględniać zgodność wsteczną ze starą wersją kodu źródłowego.
• Podczas zmiany kolumny bazy danych powinniśmy unikać bezpośredniej zmiany w schemacie, zamiast tego korzystając z podejścia do deprecjacji i migracji.
• Programista powinien być bardziej świadomy procesu wydania i harmonogramu.

Działania naprawcze i zapobiegawcze#

• ✅ Sprawdzenie zgodności wstecznej bazy danych CI jest teraz wymagane przed scaleniem PR zawierającego zmianę schematu.
• ✅ Podkreślenie znaczenia zgodności wstecznej w zespole.