Analyse post-mortem : une erreur 500 inattendue s'est produite lors de la connexion de l'utilisateur

Résumé#

Le 18 juillet 2024, Logto Cloud a connu une panne de service avec une erreur 500 sur le serveur interne des services d'authentification.

• Utilisateurs affectés : Tous les utilisateurs Cloud tentant de s'authentifier
• Régions affectées : Europe et États-Unis
• Gravité : Critique, perturbant l'expérience de connexion des utilisateurs

Cause racine#

Lors d'un déploiement Cloud récent, un changement incompatible dans le schéma de base de données a provoqué l'échec de l'API de l'expérience de connexion lors de la transition entre les environnements de stage et de production.

Chronologie#

• 2024-07-18 08:57 (UTC) : Mises à jour déployées sur Logto Cloud
• 2024-07-18 09:28 (UTC) : Premier utilisateur ayant signalé une erreur 500
• 2024-07-18 09:31 (UTC) : L'équipe de développement a reconnu le problème et a commencé à enquêter
• 2024-07-18 09:32 (UTC) : Le problème a été résolu automatiquement
• 2024-07-18 09:40 (UTC) : Cause racine identifiée

Analyse d'incident#

Quel est le changement incompatible de la base de données, et pourquoi ?#

Nous développons actuellement une nouvelle fonctionnalité appelée "Apportez votre UI", qui permet aux utilisateurs de personnaliser l'expérience de connexion Logto avec leurs propres pages web. Cette fonctionnalité nécessite une nouvelle colonne dans la table sign-in-exp pour stocker la configuration de l'UI personnalisée.

En raison de certaines modifications des exigences au cours du développement, la sortie de la fonctionnalité a été retardée, mais la première partie du changement de schéma a déjà été déployée en production il y a plusieurs semaines, bien qu'elle ne soit pas encore utilisée. Une mise à jour de la colonne de la base de données a été introduite dans ce PR.

Malheureusement, ce changement n'était pas compatible avec les versions antérieures, provoquant l'échec des requêtes API de l'ancien code lors de la communication avec la nouvelle base de données.

Comment déployons-nous une nouvelle version de Logto Cloud ?#

Lors du déploiement d'une nouvelle version de Logto Cloud, nous la déployons d'abord dans l'environnement de staging, puis nous échangeons les environnements de stage et de production. Le processus est le suivant :

1. Exécuter le script de modification de la base de données et mettre à jour la base de données.
2. Déployer le nouveau code source sur le serveur de staging.
3. Exécuter le serveur de staging et effectuer des tests.
4. Échanger les serveurs de staging et de production pour que le "staging" devienne "production", permettant aux utilisateurs d'accéder à la nouvelle version sans interruption.

Cependant, les deux environnements partagent la même base de données, et l'ensemble du processus prend du temps. Ainsi, dans la fenêtre de temps entre la mise à jour de la base de données et l'échange des environnements, les utilisateurs en ligne restent dans l'environnement de production avec l'ancien code mais tentent de communiquer avec la nouvelle base de données.

C'était la cause principale de l'incident et la raison pour laquelle il a été automatiquement résolu en 35 minutes.

Pourquoi cela n'a-t-il pas été abordé lors du processus de révision du code ?#

Nous AVONS une tâche CI pour vérifier la compatibilité avec les versions antérieures des changements de la base de données. Cependant, auparavant, il n'était pas nécessaire de réussir le contrôle CI avant de fusionner le PR. La raison en est que la phase de développement est généralement courte, en quelques sprints, et que la première et la deuxième parties des changements de schéma sont généralement incluses dans la même phase de sortie.

Cette fois-ci, la sortie de la fonctionnalité a été retardée, répartissant les changements de schéma entre deux versions. Le développeur a supposé que l'échec du CI était attendu et a informé les réviseurs que cela ne devrait pas bloquer la fusion du PR.

Il y avait également un manque de communication, et finalement, le PR a été fusionné sans fournir le support nécessaire pour la compatibilité avec les versions antérieures.

Leçons apprises#

• Lorsqu'on effectue un changement incompatible dans le schéma de la base de données, nous devons toujours prendre en compte la compatibilité avec les versions antérieures du code source.
• Lors de la modification d'une colonne de la base de données, nous devrions éviter de la changer directement dans le schéma, mais plutôt utiliser l'approche de dépréciation et de migration.
• Le développeur devrait avoir une meilleure compréhension du processus de sortie et du calendrier.

Mesures correctives et préventives#

• ✅ Le contrôle CI de la compatibilité avec les versions antérieures de la base de données est désormais requis avant de fusionner un PR contenant un changement de schéma.
• ✅ Mettre l'accent sur l'importance de la compatibilité avec les versions antérieures au sein de l'équipe.