Посмертный анализ: неожиданная ошибка 500 возникла во время входа пользователя

Резюме#

18 июля 2024 года в Logto Cloud произошел сбой службы с ошибкой 500 Внутренняя ошибка сервера от служб аутентификации.

• Затронутые пользователи: Все пользователи Cloud, пытающиеся аутентифицироваться
• Затронутые регионы: Европа и США
• Серьезность: Критическая, нарушающая процесс входа пользователей

Корневая причина#

Во время недавнего развертывания Cloud изменение структуры базы данных привело к сбою API процесса входа между тестовой и основной средами.

Хронология#

• 2024-07-18 08:57 (UTC): Обновления развернуты в Logto Cloud
• 2024-07-18 09:28 (UTC): Первый пользователь сообщил о возникшей ошибке 500
• 2024-07-18 09:31 (UTC): Команда разработчиков признала проблему и начала расследование
• 2024-07-18 09:32 (UTC): Проблема была автоматически решена
• 2024-07-18 09:40 (UTC): Установлена корневая причина

Анализ инцидента#

Что такое критическое изменение базы данных и почему оно произошло?#

Мы разрабатываем новую функцию под названием "Покажи свой UI", которая позволяет пользователям кастомизировать интерфейс входа в Logto с помощью своих веб-страниц. Эта функция требует добавления нового столбца в таблицу sign-in-exp для хранения настроек пользовательского интерфейса.

Из-за изменений в требованиях во время разработки выпуск функции был отложен, но первая часть изменений в структуре базы данных была развернута в основной среде несколько недель назад, хотя она еще не использовалась. Обновление столбца базы данных было представлено в этом PR.

К сожалению, это изменение было несовместимо с предыдущими версиями, что привело к ошибкам API запросов от старого кода при взаимодействии с новой базой данных.

Как мы развертываем новую версию Logto Cloud?#

При развертывании новой версии Logto Cloud мы сначала развертываем её в тестовой среде, а затем меняем местами тестовую и основную среды. Процесс выглядит следующим образом:

1. Запустить скрипт изменения базы данных и обновить базу данных.
2. Развернуть новый исходный код на тестовом сервере.
3. Запустить тестовый сервер и выполнить тесты.
4. Поменять тестовый и основной сервера местами, чтобы "тестовая" среда стала "основной", позволяя пользователям переходить на новую версию без простоя.

Тем не менее, обе среды используют одну и ту же базу данных, и весь процесс занимает время. Следовательно, в промежуток времени между обновлением базы данных и сменой сред, онлайн-пользователи оставались в основной среде с использованием старого кода, но пытались взаимодействовать с новой базой данных.

Это и стало корневой причиной инцидента, а также причиной того, почему проблема была автоматически решена через 35 минут.

Почему это не было учтено в процессе ревью кода?#

У нас действительно есть задача CI для проверки совместимости изменений базы данных с предыдущими версиями. Однако, ранее не требовалось проходить эту проверку перед слиянием PR. Это объясняется тем, что обычно этап разработки короткий, укладывается в несколько спринтов, и первая и вторая части изменений схемы данных часто включаются в одну фазу релиза.

На этот раз выпуск функции был отложен, из-за чего изменения схемы распределились на два релиза. Разработчик предположил, что сбой CI был ожидаемым и сообщил рецензентам, что это не должно блокировать слияние PR.

Определенно был коммуникационный разрыв, и, в конечном счете, PR был слит без необходимых мер поддержки обратной совместимости.

Извлеченные уроки#

• При внесении критических изменений в структуру базы данных всегда следует учитывать обратную совместимость с предыдущей версией исходного кода.
• При изменении столбца базы данных мы должны избегать непосредственных изменений в схеме, а вместо этого использовать подход к устареванию и миграции.
• Разработчик должен лучше осознавать процесс выпусков и график реализации.

Корректирующие и предупреждающие меры#

• ✅ Теперь проверка обратной совместимости базы данных CI обязательна для прохождения перед слиянием PR, содержащего изменение схемы.
• ✅ Подчеркнуть важность обратной совместимости внутри команды.