2024年12月11日，OpenAI经历了一场全球范围的服务中断，持续时间超过四个小时，影响了ChatGPT、API、Sora等多个重要产品。宕机事件发生在当天太平洋时间下午3:16，直到晚上7:38才得以完全恢复。这一事件引发了行业对云服务架构的深刻反思，揭示了当前技术体系中潜在的脆弱性。
造成影响
- ChatGPT：在下午5:45 PST开始显著恢复，7:01 PST完全恢复。
- API：在下午5:36 PST开始显著恢复，7:38 PST所有模型完全恢复。
- Sora：在下午7:01 PST完全恢复。
故障原因
OpenAI 在全球运营数百个 Kubernetes 集群。此次事件的根本原因是新部署的遥测服务配置错误，导致每个集群中的所有节点同时执行资源密集型的 Kubernetes API操作，尤其在大型集群中影响显著。这些操作过载了Kubernetes API服务器，瘫痪了控制平面，并且由于数据面的DNS服务依赖于控制面，最终导致数据面依赖的服务无法正常运行，系统进入雪崩式故障。
根据OpenAI发布的故障报告，此次事件的直接原因是新部署的一套遥测监控系统意外导致Kubernetes（K8S）控制平面过载。这种过载引发了一连串系统故障，其中Kubernetes的DNS服务也因控制平面瘫痪而失效，使得各服务间无法正常通信，进而加剧了故障的影响。这一事件与去年的阿里云宕机春节期间的故障有异曲同工之处，均是因循环依赖问题而导致的系统崩溃。
在深入分析故障原因时，OpenAI指出外部响应与内部监控之间的缺乏有效协调，尤其是在进行新服务配置时未能充分预见到其对系统负载的影响。这次事件不仅提醒我们在基础设施架构设计时需避免循环依赖，还进一步强调了进行详尽测试的重要性。在实际操作中，监控的关注点过于集中于服务的健康状态，未能对集群的整体负载和健康状况进行全面监控，从而未能及时发现系统异常。
Kubernetes作为现代云服务的重要基础架构，因其强大的容错能力而被广泛采用。然而，在此次事故中，K8S的控制平面负载过重直接导致了服务的瘫痪。Kubernetes的设计虽然考虑到数据平面在控制平面失效时能够继续运作，但DNS解析对其运行至关重要。OpenAI的报告强调，这一动态在故障早期并未被察觉，部分服务依赖于DNS的时间延迟导致问题显现得更加隐蔽。
故障发生后的恢复过程同样复杂。虽然OpenAI设有自动化工具检测并回滚故障部署，但由于管理接口的负载过高，故障回复时间被进一步延长。OpenAI的工程团队采用了多种方法，包括缩减集群规模、阻断Kubernetes管理API访问和扩容KubernetesAPI服务器，以此减轻控制平面负荷。一旦访问权限恢复，系统开始逐步好转，相关服务陆续恢复正常。
此次事故的主要原因包括：
- 服务解耦不足：数据面的核心服务依赖于控制面的存活，导致控制面故障时数据面无法正常运作。
- 配置错误：新遥测服务的配置导致每个节点同时进行高负载的API操作，超载了Kubernetes API服务器。
- 部署流程不完善：缺乏阶段性部署的健壮机制，未能有效控制新服务对现有系统的影响。
- 缺乏容错测试：未进行充分的错误注入测试和故障演练，导致在控制面失效时无法迅速响应。
- 紧急访问受限：在控制面失效时，工程师无法通过控制面进行快速回滚操作，形成“锁死”效应，延长了故障恢复时间。
应急措施
尽管监测工具及时检测到问题，但由于 Kubernetes 控制平面负载过重，工程师无法迅速访问控制平面进行修复。为恢复服务，团队同时采取了以下措施：
- 缩减集群规模：减少 Kubernetes API 负载。
- 阻断对 Kubernetes 管理 API 的网络访问：防止新的高负载请求。
- 扩展 Kubernetes API 服务器：增加资源以处理待处理请求。
- 移除有问题的遥测服务：防止进一步的负载增加。
- 将流量转移出受影响集群：减轻负载，逐步恢复正常服务。
通过并行实施这些措施，最终恢复了控制平面，逐步恢复了所有集群的正常运行。
故障时间线
整个故障的时间节点：
12 月 10 日：新的遥测服务被部署至登台集群，并在验证流程中符合预期。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 服务器。为此我们将实施应急机制，以保证工程师在任何情况下均可访问 Kubernetes API 服务器。
4、对 Kubernetes 数据平面与控制平面进行解耦：我们负责服务发现的 Kubernetes DNS 中的依赖项，导致 Kubernetes 数据平面与控制平面之间建立了链接。我们正投入资源将 Kubernetes 数据平面与控制平面相互解耦，借此保证控制平面无需承担处理关键任务服务及产品工作负载等责任。
5、加快恢复速度：我们将为集群启动所必需的资源提供经过改进的缓存及动态速率限制器，同时定期组织演习以保证快速、正确启动目标，实现对整体集群的快速替换
此次事件的教训不仅对OpenAI有深远影响，也为整个行业敲响了警钟。面对日益复杂的云服务架构，各大公司需更加注重基础设施构建的安全和可靠性。在对新技术进行部署前，企业需进行全面的测试，尤其要考虑到对现有系统的潜在影响。此外，建立有效的故障应急机制，以及对服务之间依赖关系的解耦，是提高企业抗风险能力的重要手段。
在未来的发展中，AI和云计算将继续扮演关键角色。而如何在提供强大应用能力的同时，保障系统的韧性与可持续发展，成为了摆在面前的巨大挑战。技术决策者需认识到，仅有创新技术并不足以确保服务的可靠性，合理的系统架构设计和全面的风险管理策略同样至关重要。
最后，OpenAI对本次故障对用户造成的影响表示歉意，并承诺将优先落实针对故障的改进措施，提升服务的可靠性。用户在选择使用AI产品时，要保持理性和审慎，充分利用市场中如简单AI等优秀工具，助力自媒体创业与内容创作。在既有的技术框架下，积极探索AI工具带来的机遇。
