Посмертный анализ: неожиданная ошибка 500 возникла во время входа пользователя
Отчет о происшествии по поводу неожиданной ошибки 500, возвращенной службами аутентификации 18 июля 2024 года.
Отчет о происшествии по поводу неожиданной ошибки 500, возвращенной службами аутентификации 18 июля 2024 года.
18 июля 2024 года в Logto Cloud произошел сбой службы с ошибкой 500 Внутренняя ошибка сервера от служб аутентификации.
Во время недавнего развертывания Cloud изменение структуры базы данных привело к сбою API процесса входа между тестовой и основной средами.
Мы разрабатываем новую функцию под названием "Покажи свой UI", которая позволяет пользователям кастомизировать интерфейс входа в Logto с помощью своих веб-страниц. Эта функция требует добавления нового столбца в таблицу sign-in-exp для хранения настроек пользовательского интерфейса.
Из-за изменений в требованиях во время разработки выпуск функции был отложен, но первая часть изменений в структуре базы данных была развернута в основной среде несколько недель назад, хотя она еще не использовалась. Обновление столбца базы данных было представлено в этом PR.
К сожалению, это изменение было несовместимо с предыдущими версиями, что привело к ошибкам API запросов от старого кода при взаимодействии с новой базой данных.
При развертывании новой версии Logto Cloud мы сначала развертываем её в тестовой среде, а затем меняем местами тестовую и основную среды. Процесс выглядит следующим образом:
Тем не менее, обе среды используют одну и ту же базу данных, и весь процесс занимает время. Следовательно, в промежуток времени между обновлением базы данных и сменой сред, онлайн-пользователи оставались в основной среде с использованием старого кода, но пытались взаимодействовать с новой базой данных.
Это и стало корневой причиной инцидента, а также причиной того, почему проблема была автоматически решена через 35 минут.
У нас действительно есть задача CI для проверки совместимости изменений базы данных с предыдущими версиями. Однако, ранее не требовалось проходить эту проверку перед слиянием PR. Это объясняется тем, что обычно этап разработки короткий, укладывается в несколько спринтов, и первая и вторая части изменений схемы данных часто включаются в одну фазу релиза.
На этот раз выпуск функции был отложен, из-за чего изменения схемы распределились на два релиза. Разработчик предположил, что сбой CI был ожидаемым и сообщил рецензентам, что это не должно блокировать слияние PR.
Определенно был коммуникационный разрыв, и, в конечном счете, PR был слит без необходимых мер поддержки обратной совместимости.