Analyse post-mortem : une erreur 500 inattendue s'est produite lors de la connexion de l'utilisateur
Rapport d'incident pour l'erreur 500 inattendue renvoyée par les services d'authentification le 18 juillet 2024.
CharlesDeveloper
Arrêtez de perdre des semaines sur l'authentification des utilisateurs
Lancez des applications sécurisées plus rapidement avec Logto. Intégrez l'authentification des utilisateurs en quelques minutes et concentrez-vous sur votre produit principal.
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.
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 :
Exécuter le script de modification de la base de données et mettre à jour la base de données.
Déployer le nouveau code source sur le serveur de staging.
Exécuter le serveur de staging et effectuer des tests.
É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.
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.
✅ 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.
