12月11日，OpenAI 出现了全球范围内的不可用故障，影响了 ChatGPT，API，Sora，Playground 和 Labs 等服务。影响范围从 12 月 11 日下午 3:16 至晚上 7:38 期间，持续时间超过四个小时，产生显著影响。
根据 OpenIA 在事后发布的故障报告（见下文），披露此次故障的直接原因是新部署了一套监控系统，压垮了 Kubernetes 控制面。然后因为控制面故障（DNS 依赖 K8S ）导致无法直接回滚这次发布，进一步放大的故障影响，导致了长时间的不可用。
其实这个故障和去年双十一 非常类似。都是全球控制面不可用，根因都是循环依赖（以及测试/发布灰度不足）。无非是阿里云是 OSS 和 IAM 之间循环依赖，OpenAI 是 DNS 和 K8S 的循环依赖。
依赖是架构设计中的大忌，就像在基础设施中放了炸药包，容易被一些临时性偶发性故障点爆。这次故障再次为我们敲响警钟。当然这次故障的原因还可以进一步深挖，比如测试/灰度不足，以及架构杂耍：
比如 K8S 官方建议的最大集群规模是 5000 节点，而我还清晰记得 OpenAI 发表过一篇吹牛文章：《我们是如何通过移除一个组件来让K8S跑到7500节点的》 —— 不仅不留冗余，还要超载压榨50%，最终，这次还真就在集群规模上翻了大车。
OpenAI 是 AI 领域的当红炸子鸡，其产品的实力与受欢迎程度毋庸置疑。这是依然无法掩盖其在基础设施上的薄弱 —— 基础设施想要搞好确实不容易，这也是为什么 AWS 和 DataDog 这样的公司赚得钵满盆翻的核心原因。
OpenAI 在去年在 PostgreSQL 数据库与 pgBouncer 连接池上也翻过大车。这两年来的在基础设施可靠性上的表现也说不上亮眼。这次故障再次说明，即使是万亿级独角兽，在非专业领域上，也照样是个草台班子。
故障复盘原文API、ChatGPT 和 Sora 出现问题
https://status.openai.com/incidents/ctrsv3lwd797
OpenAI故障报告复盘
本文详细记录了 2024 年 12 月 11 日发生的一次故障，当时所有 OpenAI 服务均出现了严重的停机问题。根源在于我们部署了新的遥测服务（telemetry service），意外导致 Kubernetes 控制平面负载过重，从而引发关键系统的连锁故障。我们将深入解析故障根本原因，概述故障处理的具体步骤，并分享我们为防止类似事件再次发生而采取的改进措施。
影响
在太平洋时间 2024 年 12 月 11 日下午 3:16 至晚上 7:38 之间，所有 OpenAI 服务均出现了严重降级或完全不可用。这起事故源于我们在所有集群中推出的新遥测服务配置，并非由安全漏洞或近期产品发布所致。从下午 3:16 开始，各产品性能均出现大幅下降。
•ChatGPT：在下午 5:45 左右开始大幅恢复，并于晚上 7:01 完全恢复。•API：在下午 5:36 左右开始大幅恢复，于晚上 7:38 所有模型全部恢复正常。•Sora：于晚上 7:01 完全恢复。
根因
OpenAI 在全球范围内运营着数百个 Kubernetes 集群。Kubernetes 的控制平面主要负责集群管理，而数据平面则实际运行工作负载（如模型推理服务）。
为提升组织整体可靠性，我们一直在加强集群级别的可观测性工具，以加深对系统运行状态的可见度。太平洋时间下午 3:12，我们在所有集群部署了一项新的遥测服务，用于收集 Kubernetes 控制平面的详细指标。
由于遥测服务会涉及非常广泛的操作范围，这项新服务的配置无意间让每个集群中的所有节点都执行了高成本的 Kubernetes API 操作，并且该操作成本会随着集群规模的扩大而成倍增加。数千个节点同时发起这些高负载请求，导致 Kubernetes API 服务器不堪重负，进而瘫痪了大型集群的控制平面。该问题在规模最大的集群中最为严重，因此在测试环境并未检测到；另一方面，DNS 缓存也使问题在正式环境中的可见度降低，直到问题在整个集群开始全面扩散后才逐渐显现。
尽管 Kubernetes 数据平面大部分情况下可独立于控制平面运行，但数据平面的 DNS 解析依赖控制平面——如果控制平面瘫痪，服务之间便无法通过 DNS 相互通信。
简而言之，新遥测服务的配置在大型集群中意外地生成了巨大的 Kubernetes API 负载，导致控制平面瘫痪，进而使 DNS 服务发现功能中断。
测试与部署
我们在一个预发布（staging）集群中对变更进行了测试，当时并未发现任何问题。该故障主要对超过一定规模的集群产生影响；再加上每个节点的 DNS 缓存延迟了故障的可见时间，使得变更在正式环境被大范围部署之前并没有暴露出任何明显异常。
在部署之前，我们最关注的是这项新遥测服务本身对系统资源（CPU/内存）的消耗。在部署前也对所有集群的资源使用情况进行了评估，确保新部署不会干扰正在运行的服务。虽然我们针对不同集群调优了资源请求，但并未考虑 Kubernetes API 服务器的负载问题。与此同时，此次变更的监控流程主要关注了服务自身的健康状态，并没有完善地监控集群健康（尤其是控制平面的健康）。
Kubernetes 数据平面（负责处理用户请求）设计上可以在控制平面离线的情况下继续工作。然而，Kubernetes API 服务器对于 DNS 解析至关重要，而 DNS 解析对于许多服务都是核心依赖。
DNS 缓存在故障早期阶段起到了暂时的缓冲作用，使得一些陈旧但可用的 DNS 记录得以继续为服务提供地址解析。但在接下来 20 分钟里，这些缓存逐步过期，依赖实时 DNS 的服务开始出现故障。这段时间差恰好在部署持续推进时才逐渐暴露问题，使得最终故障范围更为集中和明显。一旦 DNS 缓存失效，集群里的所有服务都会向 DNS 发起新请求，进一步加剧了控制平面的负载，使得故障难以在短期内得到缓解。
故障修复
在大多数情况下，监控部署和回滚有问题的变更都相对容易，我们也有自动化工具来检测和回滚故障性部署。此次事件中，我们的检测工具确实正常工作——在客户受影响前几分钟就已经发出了警报。不过要真正修复这个问题，需要先删除导致问题的遥测服务，而这需要访问 Kubernetes 控制平面。然而，API 服务器在承受巨大负载的情况下无法正常处理管理操作，导致我们无法第一时间移除故障性服务。
我们在几分钟内确认了问题，并立即启动多个工作流程，尝试不同途径迅速恢复集群：
1.缩小集群规模：通过减少节点数量来降低 Kubernetes API 总负载。2.阻断对 Kubernetes 管理 API 的网络访问：阻止新的高负载请求，让 API 服务器有时间恢复。3.扩容 Kubernetes API 服务器：提升可用资源以应对积压请求，从而为移除故障服务赢得操作窗口。
我们同时采用这三种方法，最终恢复了对部分控制平面的访问权限，从而得以删除导致问题的遥测服务。
一旦我们恢复对部分控制平面的访问权限，系统就开始迅速好转。在可能的情况下，我们将流量切换到健康的集群，同时对仍然存在问题的其他集群进行进一步修复。部分集群仍在修复过程出现资源竞争问题：很多服务同时尝试重新下载所需组件，导致资源饱和并需要人工干预。
此次事故是多项系统与流程在同一时间点相互作用、同时失效的结果，主要体现在：
•测试环境未能捕捉到新配置对 Kubernetes 控制平面的影响。•DNS 缓存使服务故障出现了时间延迟，从而让变更在故障完全暴露前被大范围部署。•故障发生时无法访问控制平面，导致修复进程十分缓慢。
时间线
•2024 年 12 月 10 日：新的遥测服务部署到预发布集群，经测试无异常。•2024 年 12 月 11 日 下午 2:23：引入该服务的代码合并到主分支，并触发部署流水线。•下午 2:51 至 3:20：变更逐步应用到所有集群。•下午 3:13：告警触发，通知到工程师。•下午 3:16：少量客户开始受到影响。•下午 3:16：根因被确认。•下午 3:27：工程师开始把流量从受影响的集群迁移。•下午 3:40：客户影响达到最高峰。•下午 4:36：首个集群恢复。•晚上 7:38：所有集群恢复。
预防措施
为防止类似事故再次发生，我们正在采取如下措施：
1. 更健壮的分阶段部署
我们将继续加强基础设施变更的分阶段部署和监控机制，确保任何故障都能被迅速发现并限制在较小范围。今后所有与基础设施相关的配置变更都会采用更全面的分阶段部署流程，并在部署过程中持续监控服务工作负载以及 Kubernetes 控制平面的健康状态。
2. 故障注入测试
Kubernetes 数据平面需要进一步增强在缺失控制平面的情况下的生存能力。我们将引入针对该场景的测试手段，包括在测试环境有意注入“错误配置”来验证系统检测和回滚能力。
3. 紧急访问 Kubernetes 控制平面
当前我们还没有一套应对数据平面向控制平面施加过大压力时，依旧能访问 API 服务器的应急机制。我们计划建立“破冰”机制（break-glass），确保在任何情况下工程团队都能访问 Kubernetes API 服务器。
4. 进一步解耦 Kubernetes 数据平面和控制平面
我们目前对 Kubernetes DNS 服务的依赖，使得数据平面和控制平面存在耦合关系。我们会投入更多精力，使得控制平面对关键服务和产品工作负载不再是“负载核心”，从而降低对 DNS 的单点依赖。
5. 更快的恢复速度
我们将针对集群启动所需的关键资源引入更完善的缓存和动态限流机制，并定期进行“快速替换整个集群”的演练，以确保在最短时间内实现正确、完整的启动和恢复。
结语
我们对这次事故造成的影响向所有客户表示诚挚的歉意——无论是 ChatGPT 用户、API 开发者还是依赖 OpenAI 产品的企业。此次事件没有达到我们自身对系统可靠性的期望。我们意识到向所有用户提供高度可靠的服务至关重要，接下来将优先落实上述防范措施，不断提升服务的可靠性。感谢大家在此次故障期间的耐心等待。
发表于 23 小时前。2024 年 12 月 12 日 - 17:19 PST
已解决
在 2024 年 12 月 11 日下午 3:16 到晚上 7:38 期间，OpenAI 的服务不可用。大约在下午 5:40 开始，我们观察到 API 流量逐渐恢复；ChatGPT 和 Sora 则在下午 6:50 左右恢复。我们在晚上 7:38 排除了故障，并使所有服务重新恢复正常。
OpenAI 将对本次事故进行完整的根本原因分析，并在此页面分享后续详情。
2024 年 12 月 11 日 - 22:23 PST
监控
API、ChatGPT 和 Sora 的流量大体恢复。我们将继续监控，确保问题彻底解决。
2024 年 12 月 11 日 - 19:53 PST
更新
我们正持续推进修复工作。API 流量正在恢复，我们逐个地区恢复 ChatGPT 流量。Sora 已开始部分恢复。
2024 年 12 月 11 日 - 18:54 PST
更新
我们正努力修复问题。API 和 ChatGPT 已部分恢复，Sora 仍然离线。
2024 年 12 月 11 日 - 17:50 PST
更新
我们正继续研发修复方案。
2024 年 12 月 11 日 - 17:03 PST
更新
我们正继续研发修复方案。
2024 年 12 月 11 日 - 16:59 PST
更新
我们已经找到一个可行的恢复方案，并开始看到部分流量成功返回。我们将继续努力，使服务尽快恢复正常。
2024 年 12 月 11 日 - 16:55 PST
更新
ChatGPT、Sora 和 API 依然无法使用。我们已经定位到问题，并正在部署修复方案。我们正在尽快恢复服务，对停机带来的影响深表歉意。
2024 年 12 月 11 日 - 16:24 PST
已确认问题
我们接到报告称 API 调用出现错误，platform.openai.com 和 ChatGPT 的登录也出现问题。我们已经确认问题，并正在开展修复。
2024 年 12 月 11 日 - 15:53 PST
更新
我们正在继续调查此问题。
2024 年 12 月 11 日 - 15:45 PST
更新
我们正在继续调查此问题。
2024 年 12 月 11 日 - 15:42 PST
调查中
我们目前正在调查该问题，很快会提供更多更新信息。
发表于 2 天前。2024 年 12 月 11 日 - 15:17 PST
本次故障影响了 API、ChatGPT、Sora、Playground 以及 Labs。