OpenAI 近日发布了关于 12月11日 ChatGPT 和 Sora 服务长达 4 小时 10 分钟宕机事件的详细报告。此次事件波及众多用户，引起了广泛关注。报告详细解释了故障原因、工程师遇到的困境以及最终恢复服务的全过程，为其他技术团队提供了宝贵的经验教训。报告中清晰地阐述了故障的根本原因，以及工程师在面对控制面崩溃时采取的一系列应急措施，体现了 OpenAI 在突发事件处理上的应对能力。
上周（12月11日）OpenAI 的 ChatGPT 和 Sora 等服务发生了长达4小时10分钟的宕机事件，导致众多用户受到影响。现在，OpenAI正式发布ChatGPT宕机故障详细报告。
简单的说这次故障的根本原因是一个小的变更，却导致了严重的后果，工程师们在关键时刻被锁在了控制面之外，无法及时处理问题。对于此次故障，OpenAI 的工程师在发现问题后迅速展开了多项修复工作，包括缩减集群规模、阻止对 Kubernetes 管理 API 的网络访问以及增加 Kubernetes API 服务器的资源。经过几轮努力，工程师们终于恢复了对部分 Kubernetes 控制平面的访问，并采取措施将流量转移到健康的集群中，最终实现了系统的全面恢复。
事故发生在太平洋标准时间下午3点12分，工程师们为收集 Kubernetes（K8S）控制面指标而部署了新的遥测服务。然而，由于该服务的配置无意间过于广泛，导致每个集群中的每个节点同时执行资源密集型的 K8S API 操作。这一情况迅速造成了 API 服务器的崩溃，从而使得大多数集群的 K8S 数据面失去了服务能力。
值得注意的是，虽然 K8S 数据面在理论上可以独立于控制面运行，但 DNS 的功能依赖于控制面，这使得服务之间无法相互联系。当 API 操作过载时，服务发现机制受损，导致了整个服务的瘫痪。虽然问题在3分钟内就被定位，但由于工程师无法访问控制面进行服务回滚，导致了一个 “死循环” 局面。控制面崩溃使得他们无法删除有问题的服务，进而无法进行恢复。
OpenAI 工程师们随即开始探索恢复集群的不同方法。他们尝试缩小集群规模以减少 K8S 的 API 负载，并阻止对管理 K8S API 的访问，以便服务器可以恢复正常运转。此外，他们还扩大了 K8S API 服务器的资源配置，以便更好地处理请求。经过一系列努力，工程师们终于重新获得了对 K8S 控制面的控制，得以删除故障服务并逐步恢复集群。
在此期间，工程师们还将流量转移到已恢复或新增的健康集群中，以降低其他集群的负载。然而，由于许多服务试图同时恢复，导致资源限制饱和，恢复过程需要额外的手动干预，部分集群恢复耗时较长。通过这次事故，OpenAI 有望总结经验，避免在未来遇到类似情况时再次被 “锁门”。
报告详情:https://status.openai.com/incidents/ctrsv3lwd797
划重点:
故障原因:小的遥测服务变更导致 K8S API 操作过载，造成服务瘫痪。
工程师困境:控制面崩溃使得工程师无法访问，导致无法进行问题处理。
⏳ 恢复过程:通过缩小集群规模和增加资源等手段，最终恢复了服务。
此次事件虽然造成了服务中断，但也为OpenAI提供了宝贵的经验，促使他们改进系统架构和应急预案，进一步提升服务稳定性，为用户提供更可靠的服务保障。 相信OpenAI会从这次事件中吸取教训，不断完善技术，为用户带来更好的体验。