Vorfallsbericht für den Ausfall des Logto-Dienstes am 17.12.2023 aufgrund des Verlusts des Produktions-Docker-Images.
Wir haben am 17.12.2023 einen Diensteseitigen Ausfall erlebt, da das Logto-Produktions-Docker-Image verloren ging.
| Zeit | Ereignis |
|---|---|
| Früher 2023-12-17 (genaue Uhrzeit unbekannt) | Logto automatisierter GitHub-Image-Rückhalteprozess wurde ausgeführt. logto und logto-cloud Produktionsimages wurden versehentlich gelöscht. |
| 2023-12-17 03:56:00 UTC | Logto-Cloud-Dienst und Logto-Kerndienst wurden nicht verfügbar. Vorfall wurde von unserem Überwachungssystem erkannt. |
| 2023-12-17 04:03:00 UTC | Vorfall wurde von unserem Bereitschaftsingenieur anerkannt. |
| 2023-12-17 04:10:00 UTC | Neue Bereitstellung des Logto-Cloud-Dienstes und Logto-Kerndienstes wurde mit dem neuesten Image ausgelöst. |
| 2023-12-17 04:15:00 UTC | Logto-Cloud-Dienst und Logto-Kerndienst wurden wieder verfügbar. Vorfall wurde automatisch gelöst. |
Logto-Produktionsimages wurden durch unseren automatisierten GitHub-Image-Rückhalteprozess gelöscht. Der Cloud-Dienst konnte das Image nicht aus dem GitHub Container Registry abrufen und wurde nicht verfügbar.
Der automatisierte GitHub-Image-Rückhalteprozess hat die Produktionsimages versehentlich gelöscht. Der Workflow war so konzipiert, dass alle nicht gekennzeichneten alten Images, die älter als 3 Tage sind, gelöscht werden.
Wir haben die Produktionsimages mit dem Tag prod versehen, um sie als Produktionsimages zu identifizieren. Jedes Mal, wenn eine Produktionsbereitstellung ausgelöst wird, wird ein neues Image mit dem Tag prod erstellt und in das GitHub Container Registry hochgeladen. Der prod Tag wird von dem alten Image entfernt, sobald das neue Image erfolgreich erstellt und hochgeladen wurde. Das alte Image wird dadurch nicht gekennzeichnet und vom automatisierten GitHub-Image-Rückhalteprozess gelöscht.
Logto-Dienst-Images wurden so aufgebaut, dass sie mehrere Architekturen unterstützen. Das Image wurde mit buildx gebaut und mit dem --platform Flag in das GitHub Container Registry hochgeladen. Alle Tags wurden auf die Hauptmanifest-Liste angewendet. Der prod Tag wurde ebenfalls auf die Hauptmanifest-Liste angewendet. Alle Teil-Images, die unter der Multi-Arch-Manifest-Liste aufgelistet sind, bleiben unmarkiert.
Aufgrund eines Mangels an sorgfältiger Überprüfung der Tag- und Manifestlistenstruktur des Docker-Images haben wir einfach den automatisierten GitHub-Image-Rückhalteprozess so konfiguriert, dass alle unmarkierten Images gelöscht werden. Der Workflow löschte alle Teil-Images, die unter der Multi-Arch-Manifest-Liste aufgeführt sind.
Dieser Vorfall führte dazu, dass der Logto-Cloud-Dienst und der Logto-Kerndienst etwa 18 Minuten lang nicht verfügbar waren. Endbenutzer konnten sich nicht bei Logto anmelden und nicht auf ihre Clientanwendungen zugreifen. Das Logto-Cloud-Admin-Portal war während des Vorfalls ebenfalls nicht verfügbar.
Wir haben den automatisierten GitHub-Image-Rückhalteprozess gestoppt und ein neues Image mit dem Tag prod in das GitHub Container Registry hochgeladen. Das neue Image wurde erfolgreich vom Logto-Cloud-Dienst und dem Logto-Kerndienst abgerufen. Der Dienst wurde wieder verfügbar.