OpenAI publicó recientemente un informe detallado sobre la interrupción de 4 horas y 10 minutos de los servicios ChatGPT y Sora el 11 de diciembre. Este incidente afectó a muchos usuarios y atrajo una atención generalizada. El informe explica en detalle la causa de la falla, las dificultades encontradas por los ingenieros y el proceso final de restauración del servicio, brindando lecciones valiosas para otros equipos técnicos. El informe explica claramente la causa raíz del fallo, así como una serie de medidas de emergencia tomadas por los ingenieros ante un accidente de avión de control, lo que refleja la capacidad de OpenAI para responder a emergencias.
La semana pasada (11 de diciembre), los servicios ChatGPT y Sora de OpenAI estuvieron inactivos durante 4 horas y 10 minutos, lo que afectó a muchos usuarios. Ahora, OpenAI publica oficialmente un informe detallado sobre la interrupción de ChatGPT.
En pocas palabras, la causa fundamental de esta falla fue un pequeño cambio, pero tuvo consecuencias graves. Los ingenieros quedaron excluidos de la superficie de control en el momento crítico y no pudieron solucionar el problema a tiempo. Con respecto a esta falla, los ingenieros de OpenAI rápidamente lanzaron una serie de reparaciones después de descubrir el problema, incluida la reducción del tamaño del clúster, el bloqueo del acceso de red a la API de administración de Kubernetes y el aumento de los recursos del servidor API de Kubernetes. Después de varias rondas de esfuerzos, los ingenieros finalmente restauraron el acceso a parte del plano de control de Kubernetes y tomaron medidas para desviar el tráfico a clústeres saludables, logrando finalmente una recuperación completa del sistema.
El incidente ocurrió a las 3:12 p. m. PST cuando los ingenieros implementaron un nuevo servicio de telemetría para recopilar métricas del plano de control de Kubernetes (K8S). Sin embargo, la configuración del servicio fue involuntariamente demasiado amplia, lo que provocó que cada nodo de cada clúster realizara simultáneamente operaciones API K8S que consumían muchos recursos. Esta situación rápidamente provocó que el servidor API fallara, lo que provocó que el plano de datos K8S de la mayoría de los clústeres perdiera capacidades de servicio.
Vale la pena señalar que, aunque en teoría el plano de datos K8S puede ejecutarse independientemente del plano de control, la funcionalidad de DNS depende del plano de control, lo que hace imposible que los servicios se comuniquen entre sí. Cuando las operaciones de API se sobrecargan, el mecanismo de descubrimiento de servicios se daña, lo que provoca la parálisis de todo el servicio. Aunque el problema se localizó en 3 minutos, el ingeniero no pudo acceder al plano de control para revertir el servicio, lo que resultó en una situación de "bucle infinito". Un accidente del avión de control les impidió retirar el servicio problemático y, por tanto, imposibilitó la recuperación.
Los ingenieros de OpenAI inmediatamente comenzaron a explorar diferentes formas de restaurar el clúster. Intentaron reducir el tamaño del clúster para reducir la carga de API en K8S y bloquearon el acceso a la API de administración de K8S para que los servidores pudieran reanudar sus operaciones normales. Además, también ampliaron la configuración de recursos del servidor API K8S para manejar mejor las solicitudes. Después de una serie de esfuerzos, los ingenieros finalmente recuperaron el control del plano de control K8S, pudieron eliminar el servicio defectuoso y restaurar gradualmente el clúster.
Durante este período, los ingenieros también trasladaron el tráfico a clústeres en buen estado restaurados o recién agregados para reducir la carga en otros clústeres. Sin embargo, como muchos servicios intentaron recuperarse al mismo tiempo, lo que provocó una saturación del límite de recursos, el proceso de recuperación requirió intervención manual adicional y la recuperación de algunos clústeres llevó mucho tiempo. A través de este incidente, se espera que OpenAI aprenda de su experiencia y evite ser "bloqueado" nuevamente cuando se encuentre con situaciones similares en el futuro.
Detalles del informe: https://status.openai.com/incidents/ctrsv3lwd797
Reflejos:
Causa del error: pequeños cambios en el servicio de telemetría provocaron que las operaciones de la API de K8S se sobrecargaran, lo que provocó la parálisis del servicio.
El dilema del ingeniero: un accidente en el avión de control hace que los ingenieros sean inaccesibles, lo que hace imposible manejar el problema.
⏳ Proceso de recuperación: Al reducir el tamaño del cluster y aumentar los recursos, finalmente se restableció el servicio.
Aunque este incidente provocó la interrupción del servicio, también proporcionó a OpenAI una experiencia valiosa, lo que los impulsó a mejorar la arquitectura de su sistema y los planes de emergencia, mejorar aún más la estabilidad del servicio y brindar a los usuarios garantías de servicio más confiables. Creo que OpenAI aprenderá de este incidente, continuará mejorando su tecnología y brindará una mejor experiencia a los usuarios.