Postmortem: se produjo un error inesperado 500 durante el inicio de sesión del usuario

Resumen#

El 18 de julio de 2024, Logto Cloud experimentó una interrupción del servicio con un error 500 de servidor interno en los servicios de autenticación.

• Usuarios afectados: Todos los usuarios de Cloud que intentaron autenticar
• Regiones afectadas: Europa y EE. UU.
• Severidad: Crítica, interrumpiendo la experiencia de inicio de sesión del usuario

Causa raíz#

Durante un despliegue reciente en Cloud, un cambio que rompía la estructura de la base de datos causó que la API de experiencia de inicio de sesión fallara durante la transición entre los entornos de pruebas y producción.

Línea de tiempo#

• 2024-07-18 08:57 (UTC): Actualizaciones desplegadas en Logto Cloud
• 2024-07-18 09:28 (UTC): Primer usuario reporta un error 500
• 2024-07-18 09:31 (UTC): El equipo de desarrollo reconoció el problema y comenzó a investigarlo
• 2024-07-18 09:32 (UTC): El problema se resolvió automáticamente
• 2024-07-18 09:40 (UTC): Se identificó la causa raíz

Análisis del incidente#

¿Cuál es el cambio que rompió la base de datos y por qué?#

Actualmente estamos desarrollando una nueva función llamada "Trae tu UI", que permite a los usuarios personalizar la experiencia de inicio de sesión de Logto con sus propias páginas web. Esta función requiere una nueva columna en la tabla sign-in-exp para almacenar la configuración de UI personalizada.

Debido a algunos cambios en los requisitos durante el desarrollo, el lanzamiento de la función se retrasó, pero la primera parte del cambio en la estructura de la base de datos ya se desplegó en producción hace varias semanas, a pesar de que aún no está en uso. Una actualización de la columna de la base de datos se introdujo en este PR.

Desafortunadamente, este cambio no era compatible hacia atrás, lo que causaba que las solicitudes de API del código antiguo fallaran al comunicarse con la nueva base de datos.

¿Cómo desplegamos una nueva versión de Logto Cloud?#

Al desplegar una nueva versión de Logto Cloud, primero la desplegamos en el entorno de pruebas y luego intercambiamos los entornos de pruebas y producción. El proceso es el siguiente:

1. Ejecutar el script de alteración de base de datos y actualizar la base de datos.
2. Desplegar el nuevo código fuente en el servidor de pruebas.
3. Ejecutar el servidor de pruebas y realizar pruebas.
4. Intercambiar los servidores de pruebas y producción para que las "pruebas" se conviertan en "producción", permitiendo a los usuarios acceder a la nueva versión sin tiempo de inactividad.

Sin embargo, ambos entornos comparten la misma base de datos y todo el proceso lleva tiempo. Entonces, en la ventana de tiempo entre la actualización de la base de datos y el intercambio de entornos, los usuarios en línea permanecen en el entorno de producción con el código antiguo pero intentan comunicarse con la nueva base de datos.

Esta fue la causa raíz del incidente y la razón por la que se resolvió automáticamente en 35 minutos.

¿Por qué no se abordó esto en el proceso de revisión de código?#

Sí TENEMOS una tarea de CI para verificar la compatibilidad hacia atrás de los cambios en la base de datos. Sin embargo, anteriormente no era necesario aprobar la verificación de CI antes de fusionar el PR. Esto se debe a que la mayor parte del tiempo la fase de desarrollo es usualmente corta, dentro de unas pocas sprints, y la primera y segunda parte de los cambios en la estructura de la base de datos generalmente se incluyen en la misma fase de lanzamiento.

Esta vez, el lanzamiento de la función se retrasó, extendiendo los cambios en la estructura de la base de datos a dos lanzamientos. El desarrollador asumió que la falla en el CI era esperada e informó a los revisores que no debería bloquear la fusión del PR.

Definitivamente hubo una brecha de comunicación y, finalmente, el PR se fusionó sin proporcionar el soporte necesario para la compatibilidad hacia atrás.

Lecciones aprendidas#

• Al hacer un cambio que rompe la compatibilidad en la estructura de la base de datos, siempre debemos considerar la compatibilidad hacia atrás con la versión anterior del código fuente.
• Al alterar una columna de la base de datos, debemos evitar cambiarla directamente en la estructura, y en su lugar usar un enfoque de deprecación y migración.
• El desarrollador debe tener más conciencia del proceso de lanzamiento y la línea de tiempo.

Medidas correctivas y preventivas#

• ✅ Ahora es obligatorio aprobar la verificación de compatibilidad hacia atrás de la base de datos en CI antes de fusionar un PR que contenga cambios en la estructura.
• ✅ Enfatizar la importancia de la compatibilidad hacia atrás dentro del equipo.