Postmortem: Unerwarteter 500-Fehler bei der Benutzeranmeldung aufgetreten

Zusammenfassung#

Am 18. Juli 2024 erlebte Logto Cloud einen Dienstausfall mit einem 500-Internen-Serverfehler von den Authentifizierungsdiensten.

• Betroffene Benutzer: Alle Cloud-Benutzer, die versucht haben, sich zu authentifizieren
• Betroffene Regionen: Europa und USA
• Schweregrad: Kritisch, Benutzeranmeldungserfahrung gestört

Ursächliche Ursache#

Während einer kürzlichen Bereitstellung in der Cloud führte eine inkompatible Änderung im Datenbankschema dazu, dass die API für die Anmeldung während des Übergangs zwischen der Staging- und Produktionsumgebung ausfiel.

Zeitachse#

• 2024-07-18 08:57 (UTC): Updates wurden auf Logto Cloud bereitgestellt
• 2024-07-18 09:28 (UTC): Der erste Benutzer meldete einen 500-Fehler
• 2024-07-18 09:31 (UTC): Das Entwicklungsteam erkannte das Problem und begann mit der Untersuchung
• 2024-07-18 09:32 (UTC): Das Problem wurde automatisch behoben
• 2024-07-18 09:40 (UTC): Ursache identifiziert

Vorfallanalyse#

Was ist die inkompatible Änderung im Datenbankschema und Warum?#

Wir entwickeln derzeit ein neues Feature namens "Bringe dein UI mit", das es Benutzern ermöglicht, das Anmeldeerlebnis von Logto mit ihren eigenen Webseiten anzupassen. Dieses Feature erfordert eine neue Spalte in der sign-in-exp-Tabelle, um die benutzerdefinierte UI-Konfiguration zu speichern.

Aufgrund einiger Anforderungsänderungen während der Entwicklung wurde die Feature-Veröffentlichung verzögert, aber der erste Teil der Schemaänderung wurde bereits vor mehreren Wochen in die Produktion eingeführt, obwohl er noch nicht verwendet wurde. Ein Update der Datenbanksäule wurde in diesem PR eingeführt.

Leider war diese Änderung nicht rückwärtskompatibel, wodurch API-Anfragen vom alten Code fehlschlugen, wenn sie mit der neuen Datenbank kommunizierten.

Wie wird eine neue Version von Logto Cloud bereitgestellt?#

Beim Bereitstellen einer neuen Version von Logto Cloud wird diese zuerst in der Staging-Umgebung bereitgestellt und dann werden die Staging- und Produktionsumgebungen ausgetauscht. Der Prozess ist wie folgt:

1. Führen Sie das Skript zur Datenbankänderung aus und aktualisieren Sie die Datenbank.
2. Bereitstellen des neuen Quellcodes auf dem Staging-Server.
3. Führen Sie den Staging-Server aus und führen Sie Tests durch.
4. Tauschen Sie die Staging- und Produktionsserver, sodass das "Staging" zu "Produktion" wird, was den Benutzern den Zugriff auf die neue Version ohne Ausfallzeiten ermöglicht.

Beide Umgebungen nutzen jedoch dieselbe Datenbank, und der gesamte Prozess benötigt Zeit. In dem Zeitfenster zwischen der Datenbankaktualisierung und dem Umgebungswechsel bleiben die Online-Benutzer in der Produktionsumgebung mit dem alten Code, versuchen jedoch, mit der neuen Datenbank zu kommunizieren.

Dies war die ursächliche Ursache des Vorfalls und der Grund dafür, dass er sich nach 35 Minuten automatisch löste.

Warum wurde dies im Code-Überprüfungsprozess nicht angesprochen?#

Wir HABEN eine CI-Aufgabe, um die Rückwärtskompatibilität der Datenbankänderungen zu überprüfen. Allerdings war es früher nicht erforderlich, den CI-Check zu bestehen, bevor ein PR zusammengeführt wurde. Dies liegt daran, dass die Entwicklungsphasen meistens kurz über ein paar Sprints hinweg sind und der erste und zweite Teil der Schemaänderungen normalerweise in derselben Veröffentlichungsphase enthalten sind.

Dieses Mal wurde die Feature-Veröffentlichung jedoch verzögert, und die Schemaänderungen wurden über zwei Veröffentlichungen verteilt. Der Entwickler ging davon aus, dass das CI-Versagen zu erwarten war, und informierte die Reviewer, dass dies den PR nicht blockieren sollte.

Es gab definitiv eine Kommunikationslücke, und schließlich wurde der PR ohne jegliche notwendige Unterstützung für die Rückwärtskompatibilität zusammengeführt.

Lektionen gelernt#

• Wenn eine inkompatible Änderung im Datenbankschema vorgenommen wird, sollte immer die Rückwärtskompatibilität mit der alten Version des Quellcodes berücksichtigt werden.
• Beim Ändern einer Datenbanksäule sollten wir vermeiden, sie direkt im Schema zu ändern, sondern stattdessen den Deprecation- und Migrationsansatz verwenden.
• Der Entwickler sollte sich mehr des Release-Prozesses und des Zeitplans bewusst sein.

Korrektiv- und Präventivmaßnahmen#

• ✅ Der CI-Check zur Rückwärtskompatibilität der Datenbank ist nun erforderlich, um bestanden zu werden, bevor ein PR, der Schemaänderungen enthält, zusammengeführt werden kann.
• ✅ Betonung der Bedeutung der Rückwärtskompatibilität im Team.