Vorfallbericht über den unerwarteten 500-Fehler, der am 18. Juli 2024 von den Authentifizierungsdiensten zurückgegeben wurde.
Am 18. Juli 2024 erlebte Logto Cloud einen Dienstausfall mit einem 500-Internen-Serverfehler von den Authentifizierungsdiensten.
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.
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.
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:
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.
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.