上周（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 操作过载，造成服务瘫痪。
🚪 工程师困境:控制面崩溃使得工程师无法访问，导致无法进行问题处理。
⏳ 恢复过程:通过缩小集群规模和增加资源等手段，最终恢复了服务。