OpenAI hat kürzlich einen detaillierten Bericht über den 4 Stunden und 10 Minuten dauernden Ausfall der ChatGPT- und Sora-Dienste am 11. Dezember veröffentlicht. Dieser Vorfall betraf viele Benutzer und erregte große Aufmerksamkeit. Der Bericht erläutert ausführlich die Ursache des Ausfalls, die Schwierigkeiten, auf die die Ingenieure gestoßen sind, und den abschließenden Prozess der Wiederherstellung des Betriebs und liefert wertvolle Erkenntnisse für andere technische Teams. Der Bericht erläutert klar die Grundursache des Ausfalls sowie eine Reihe von Notfallmaßnahmen, die von Ingenieuren bei einem Absturz eines Kontrollflugzeugs ergriffen werden, was die Fähigkeit von OpenAI widerspiegelt, auf Notfälle zu reagieren.
Letzte Woche (11. Dezember) waren die ChatGPT- und Sora-Dienste von OpenAI für 4 Stunden und 10 Minuten ausgefallen, was viele Benutzer betraf. Jetzt veröffentlicht OpenAI offiziell einen detaillierten Bericht zum ChatGPT-Ausfall.
Um es einfach auszudrücken: Die Ursache dieses Fehlers war eine kleine Änderung, die jedoch schwerwiegende Folgen hatte. Die Ingenieure waren im kritischen Moment von der Steueroberfläche ausgeschlossen und konnten das Problem nicht rechtzeitig beheben. Bezüglich dieses Fehlers leiteten die OpenAI-Ingenieure schnell eine Reihe von Reparaturen ein, nachdem sie das Problem entdeckt hatten, darunter die Reduzierung der Clustergröße, die Blockierung des Netzwerkzugriffs auf die Kubernetes-Verwaltungs-API und die Erhöhung der Ressourcen des Kubernetes-API-Servers. Nach mehreren Bemühungen stellten die Ingenieure schließlich den Zugriff auf einen Teil der Kubernetes-Steuerungsebene wieder her und ergriffen Maßnahmen, um den Datenverkehr auf fehlerfreie Cluster umzuleiten, wodurch letztendlich eine vollständige Wiederherstellung des Systems erreicht wurde.
Der Vorfall ereignete sich um 15:12 Uhr PST, als Ingenieure einen neuen Telemetriedienst zur Erfassung von Kubernetes (K8S)-Kontrollebenenmetriken einsetzten. Der Dienst wurde jedoch unbeabsichtigt zu weit gefasst, was dazu führte, dass jeder Knoten in jedem Cluster gleichzeitig ressourcenintensive K8S-API-Vorgänge ausführte. Diese Situation führte schnell zum Absturz des API-Servers, wodurch die K8S-Datenebene der meisten Cluster ihre Dienstfunktionen verlor.
Es ist erwähnenswert, dass die K8S-Datenebene zwar theoretisch unabhängig von der Kontrollebene laufen kann, die Funktionalität von DNS jedoch auf der Kontrollebene beruht, was es den Diensten unmöglich macht, miteinander zu kommunizieren. Wenn API-Operationen überlastet sind, wird der Diensterkennungsmechanismus beschädigt, was zur Lähmung des gesamten Dienstes führt. Obwohl das Problem innerhalb von drei Minuten lokalisiert wurde, konnte der Techniker nicht auf die Steuerungsebene zugreifen, um den Dienst zurückzusetzen, was zu einer „Endlosschleifen“-Situation führte. Ein Absturz der Kontrollebene verhinderte die Entfernung des problematischen Dienstes und machte somit eine Wiederherstellung unmöglich.
Die OpenAI-Ingenieure begannen sofort mit der Suche nach verschiedenen Möglichkeiten zur Wiederherstellung des Clusters. Sie versuchten, die Clustergröße zu reduzieren, um die API-Last auf K8S zu verringern, und blockierten den Zugriff auf die Management-K8S-API, damit die Server ihren normalen Betrieb wieder aufnehmen konnten. Darüber hinaus haben sie auch die Ressourcenkonfiguration des K8S-API-Servers erweitert, um Anfragen besser verarbeiten zu können. Nach einer Reihe von Bemühungen erlangten die Ingenieure schließlich die Kontrolle über die K8S-Steuerungsebene zurück, konnten den fehlerhaften Dienst löschen und den Cluster schrittweise wiederherstellen.
Während dieser Zeit haben die Techniker den Datenverkehr auch auf wiederhergestellte oder neu hinzugefügte fehlerfreie Cluster verlagert, um die Belastung anderer Cluster zu verringern. Da jedoch viele Dienste gleichzeitig eine Wiederherstellung versuchten, was zu einer Überlastung der Ressourcengrenzen führte, erforderte der Wiederherstellungsprozess zusätzliche manuelle Eingriffe und die Wiederherstellung einiger Cluster dauerte lange. Es wird erwartet, dass OpenAI durch diesen Vorfall aus seinen Erfahrungen lernt und verhindert, dass es bei ähnlichen Situationen in der Zukunft erneut „ausgesperrt“ wird.
Berichtsdetails: https://status.openai.com/incidents/ctrsv3lwd797
Highlight:
Fehlerursache: Kleine Änderungen am Telemetriedienst führten zu einer Überlastung der K8S-API-Vorgänge, was zu einer Dienstlähmung führte.
Dilemma des Ingenieurs: Ein Absturz in der Kontrollebene macht Ingenieure unzugänglich und macht es unmöglich, das Problem zu lösen.
⏳ Wiederherstellungsprozess: Durch die Reduzierung der Clustergröße und die Erhöhung der Ressourcen wurde der Dienst schließlich wiederhergestellt.
Obwohl dieser Vorfall zu einer Dienstunterbrechung führte, lieferte er OpenAI auch wertvolle Erfahrungen und veranlasste das Unternehmen, seine Systemarchitektur und Notfallpläne zu verbessern, die Dienststabilität weiter zu verbessern und den Benutzern zuverlässigere Dienstgarantien zu bieten. Ich glaube, dass OpenAI aus diesem Vorfall lernen, seine Technologie weiter verbessern und den Benutzern ein besseres Erlebnis bieten wird.