OpenAI a récemment publié un rapport détaillé sur la panne de 4 heures et 10 minutes des services ChatGPT et Sora le 11 décembre. Cet incident a touché de nombreux utilisateurs et a attiré une large attention. Le rapport explique en détail la cause de la panne, les difficultés rencontrées par les ingénieurs et le processus final de rétablissement du service, fournissant ainsi de précieuses leçons aux autres équipes techniques. Le rapport explique clairement la cause profonde de l'échec, ainsi qu'une série de mesures d'urgence prises par les ingénieurs face à un crash d'avion de contrôle, ce qui reflète la capacité d'OpenAI à répondre aux urgences.
La semaine dernière (11 décembre), les services ChatGPT et Sora d'OpenAI ont été interrompus pendant 4 heures et 10 minutes, affectant de nombreux utilisateurs. Désormais, OpenAI publie officiellement un rapport détaillé sur la panne de ChatGPT.
Pour faire simple, la cause fondamentale de cet échec était un petit changement, mais cela a entraîné de graves conséquences. Les ingénieurs ont été exclus de la surface de contrôle au moment critique et n'ont pas pu résoudre le problème à temps. Concernant cette panne, les ingénieurs d'OpenAI ont rapidement lancé un certain nombre de réparations après avoir découvert le problème, notamment en réduisant la taille du cluster, en bloquant l'accès réseau à l'API de gestion Kubernetes et en augmentant les ressources du serveur API Kubernetes. Après plusieurs séries d'efforts, les ingénieurs ont finalement rétabli l'accès à une partie du plan de contrôle Kubernetes et ont pris des mesures pour détourner le trafic vers des clusters sains, parvenant finalement à une récupération complète du système.
L'incident s'est produit à 15 h 12 PST alors que les ingénieurs déployaient un nouveau service de télémétrie pour collecter les métriques du plan de contrôle Kubernetes (K8S). Cependant, le service a été involontairement configuré de manière trop large, ce qui a obligé chaque nœud de chaque cluster à effectuer simultanément des opérations d'API K8S gourmandes en ressources. Cette situation a rapidement provoqué le crash du serveur API, entraînant la perte des capacités de service du plan de données K8S de la plupart des clusters.
Il convient de noter que bien que le plan de données K8S puisse théoriquement fonctionner indépendamment du plan de contrôle, la fonctionnalité du DNS repose sur le plan de contrôle, ce qui rend impossible la communication des services entre eux. Lorsque les opérations de l'API sont surchargées, le mécanisme de découverte du service est endommagé, entraînant la paralysie de l'ensemble du service. Bien que le problème ait été localisé en 3 minutes, l'ingénieur n'a pas pu accéder au plan de contrôle pour restaurer le service, ce qui a entraîné une situation de « boucle infinie ». Un crash d’avion de contrôle les a empêchés de supprimer le service problématique, rendant ainsi la récupération impossible.
Les ingénieurs d'OpenAI ont immédiatement commencé à explorer différentes manières de restaurer le cluster. Ils ont tenté de réduire la taille du cluster pour réduire la charge de l'API sur K8S et ont bloqué l'accès à l'API de gestion K8S afin que les serveurs puissent reprendre leurs opérations normales. En outre, ils ont également étendu la configuration des ressources du serveur API K8S pour mieux gérer les demandes. Après une série d'efforts, les ingénieurs ont finalement repris le contrôle du plan de contrôle K8S, ont pu supprimer le service défectueux et restaurer progressivement le cluster.
Au cours de cette période, les ingénieurs ont également déplacé le trafic vers des clusters sains restaurés ou nouvellement ajoutés afin de réduire la charge sur les autres clusters. Cependant, comme de nombreux services tentaient de récupérer en même temps, ce qui entraînait une saturation des ressources, le processus de récupération nécessitait une intervention manuelle supplémentaire et la récupération de certains clusters prenait beaucoup de temps. Grâce à cet incident, OpenAI devrait tirer les leçons de son expérience et éviter d'être à nouveau « exclu » lorsqu'il sera confronté à des situations similaires à l'avenir.
Détails du rapport : https://status.openai.com/incidents/ctrsv3lwd797
Souligner:
Cause de l'échec : de petites modifications du service de télémétrie ont entraîné une surcharge des opérations de l'API K8S, entraînant une paralysie du service.
Dilemme de l'ingénieur : un crash dans le plan de contrôle rend les ingénieurs inaccessibles, ce qui rend impossible la gestion du problème.
⏳ Processus de récupération : En réduisant la taille du cluster et en augmentant les ressources, le service a finalement été restauré.
Bien que cet incident ait provoqué une interruption du service, il a également fourni à OpenAI une expérience précieuse, les incitant à améliorer leur architecture système et leurs plans d'urgence, à améliorer encore la stabilité du service et à offrir aux utilisateurs des garanties de service plus fiables. Je pense qu'OpenAI tirera les leçons de cet incident, continuera d'améliorer sa technologie et d'apporter une meilleure expérience aux utilisateurs.