OpenAI 服务故障CaseStudy来了！原来大厂也犯这样的错

美西时间12日，OpenAI给出了官方解释，他们犯了所有互联网公司都曾犯过的错。原来这次故障是因为升级导致的。他们本意是想提升集群的可观测性，因此，需要安装监控服务，然而这些新服务会有一些耗资源的重操作，并且这些操作负载成本会随集群规模扩大而扩大（这也是小规模测试时未发现的原因），上线后任务同时执行，导致了控制面瘫痪(笔者猜测可能是节点上的监控都需要写入读取配置导致etcd负载过高，致使API Server无法处理请求)。更不幸的是，负责接受用户推理等工作负载的数据面服务依赖了控制面的DNS服务解析，这就使得对外提供业务服务不能正常工作，而外部流量压力也会进一步导致控制面服务难以恢复（雪崩），最后不得不通过限流、加资源的方式恢复。

看到这个结果，只能说原来大家都会犯同样的错。对于一个高可用的系统，首先应该确保控制面和负责业务的workload服务解耦，因为控制面通常就是一些管理功能，不会直接承担业务负载，通常SLA也并不高。我们需要保证的是就算控制面的系统出现问题，也不应该影响正常的对外业务服务，就像之前阿里的故障，一个后台用户权限管理更新错误导致大面积的云服务不可用，这种问题是需要首先避免的。另一方面，在更新时，应该做好灰度，避免出现不当错误能力及时恢复，不然就会导致雪崩的现象，外部流量会压得服务根本无法起的起来，进而服务迟迟难以恢复。

而OpenAI这次也算是两个雷都踩了一遍，当然也不能全归咎于OpenAI，K8s自己的机制也需要承担一部分责任。不难想象，随着AI技术从探索到落地，业务服务的稳定性就变得尤为重要，除了应用开发技术外，传统的工程架构作为一切的基础也应该受到重视。

另外，OpenAI的CaseStudy写的很不错，值得作为模版学习。

下面是原文：

简介

此事后分析详细记录了 2024 年 12 月 11 日发生的事件，在该事件中，所有 OpenAI 服务经历了严重的停机时间。问题源于新部署的遥测服务无意中压垮了 Kubernetes 控制平面，导致关键系统出现级联故障。在这次事后分析中，我们将剖析根本原因，概述采取的补救措施，并分享我们实施的预防类似事件的措施。

影响

从 2024 年 12 月 11 日下午 3:16 太平洋标准时间到下午 7:38，所有 OpenAI 服务经历了显著的性能下降或完全不可用。这次事件是由于内部更改以在整个机群中推出新的遥测数据所致，并非由安全事件或最近的发布引起。所有产品在下午 3:16 开始出现性能下降。

• ChatGPT: 5:45 PM 时出现了显著恢复，7:01 PM PST 完全恢复。
• API: 在下午 5:36 时出现了显著恢复，所有模型在太平洋时间下午 7:38 时完全恢复。
• Sora: 北美太平洋时间晚上 7 点 01 分完全恢复。

根本原因

OpenAI 全球运营着数百个 Kubernetes 集群。Kubernetes 有一个控制平面负责集群管理，还有一个数据平面从这里我们实际上提供像模型推理这样的工作负载服务。

为了提高组织内的可靠性，我们一直在努力改进集群级可观测性工具，以增强对我们系统状态的可见性。美国太平洋时间下午 3:12，我们部署了一个新的遥测服务来收集详细的 Kubernetes 控制平面指标。

遥测服务的覆盖面非常广泛，因此这项新服务的配置无意中导致每个集群中的每个节点执行资源密集型的 Kubernetes API 操作，这些操作的成本随着集群规模的增大而增加。成千上万的节点同时执行这些操作，使得 Kubernetes API Server不堪重负，在大多数大型集群中导致 Kubernetes 控制平面宕机。这个问题在我们最大的集群中最为明显，因此我们的测试没有发现这个问题——直到全集群范围内的发布开始后，DNS 缓存才使得这个问题变得不那么明显。Kubernetes 的数据平面可以很大程度上独立于控制平面运行，但 DNS 依赖于控制平面——没有 Kubernetes 控制平面，服务之间不知道如何相互联系。

简而言之，根本原因是新的遥测服务配置意外地在大型集群中产生了大量的 Kubernetes API 负载，压垮了控制平面并打破了基于 DNS 的服务发现。

测试与部署

变更在测试集群中测试，未发现任何问题。影响仅限于超过一定规模的集群，并且我们每个节点上的 DNS 缓存延迟了可见故障足够长的时间，以便于部署继续进行。

我们部署前的主要可靠性担忧是新遥测服务的资源消耗。在部署前，我们评估了所有集群（CPU/内存）的资源利用率指标，以确保部署不会干扰运行中的服务。虽然对每个集群进行了资源请求的调整，但没有采取措施评估 Kubernetes API Server负载。这个发布过程监控了服务健康状况，但缺乏足够的集群健康监控协议。

Kubernetes 数据平面（负责处理用户请求）被设计为独立于控制平面运行。然而，Kubernetes API Server对于 DNS 解析是必需的，这对于许多服务来说是一个关键依赖。

DNS 缓存暂时缓解了影响，通过提供陈旧但功能正常的 DNS 记录。然而，在接下来的 20 分钟内，随着缓存记录过期，由于依赖实时 DNS 解析，服务开始失效。这一时间点至关重要，因为它延迟了问题的可见性，使得在完全理解问题范围之前，发布工作继续进行。一旦 DNS 缓存为空，对 DNS 服务器的负载被成倍放大，进一步增加了控制平面的负载，并使即时缓解变得更加复杂。

修复

监控部署并回滚违规更改通常很简单，我们有工具来检测和回滚不良部署。在这种情况下，我们的检测工具起作用了，我们在客户开始受到影响几分钟前发现了问题。但解决这个问题需要我们移除违规服务。为了进行这个修复，我们需要访问 Kubernetes 控制平面——但由于 Kubernetes API Server的负载增加，我们无法做到这一点。

我们几分钟内就锁定了问题，并立即启动了多个工作流来探索快速将集群恢复上线的不同方式：

1. 缩小区群规模：减少了总体 Kubernetes API 负载。
2. 阻断对 Kubernetes 管理员 API 的网络访问：防止新的昂贵请求，给 API Server留出恢复时间。
3. 扩大 Kubernetes API Server的规模：增加可用资源以处理待处理请求，使我们能够应用修复。

通过同时追求这三个目标，我们最终恢复了足够的控制以移除那个违规的服务。

一旦我们重新获得了对一些 Kubernetes 控制平面的访问权限，我们就开始看到立即恢复的迹象。在可能的情况下，我们将流量转向健康的集群，同时对其他集群进行修复工作。由于许多服务尝试同时下载资源，导致资源限制饱和，一些集群仍然处于降级状态，需要额外的手动干预。

这是一次多个系统和流程同时失效并以意想不到的方式相互作用的情况。具体而言——

• 我们的测试没有捕捉到变更对 Kubernetes 控制面的影响。
• DNS 缓存导致在服务开始失败与进行更改之间存在延迟。
• 修复非常缓慢，因为存在锁定效应。

时间轴

• 2024 年 12 月 10 日：新的遥测服务部署到一个预生产集群，并验证其按预期工作
• 2024 年 12 月 11 日 14:23：引入新服务的更改已合并，并触发了部署管道
• 2:51pm 至 3:20pm：变更已应用于所有集群
• 3:13pm: 发出警报，通知工程师
• 3:16pm: 小范围客户受到影响
• 3:16pm: 根本原因已确定
• 3:27pm: 工程师开始将交通从受影响的集群中转移开
• 3:40pm: 最大客户影响
• 4:36pm: 第一个集群恢复
• 7:38pm: 所有集群已恢复

预防

为防止类似事件发生，我们正在采取以下措施：

1. 坚实分阶段推出

我们继续改进分阶段部署工作，并对所有基础设施变更进行更好的监控，以确保任何故障的影响有限并能早期检测。从现在起，所有与基础设施相关的配置变更都将遵循一个 robust 分阶段部署流程，并通过改进的持续监控确保服务工作负载和集群（包括 Kubernetes 控制平面）的健康状态。

2. 故障注入测试

Kubernetes 数据平面应该能够在没有控制平面的情况下存活更长时间，我们将运行明确测试这种场景的测试。我们还将运行测试以故意推出不良变更，以确保我们的系统能够检测并回滚。

3. 紧急情况下的 Kubernetes 控制平面访问

我们尚未有机制在数据平面对控制平面施加过多压力时确保访问 API Server。我们将实现应急机制以确保工程师在任何情况下都能访问 Kubernetes API Server。

4. 将 Kubernetes 数据平面和控制平面解耦

我们对 Kubernetes DNS 的依赖为服务发现创建了 Kubernetes 数据平面和控制平面之间的联系。我们正在投资建立系统以解耦 Kubernetes 数据平面和控制平面，从而使控制平面不再承担处理关键服务和产品工作负载的负载。

5. 更快的恢复

我们将实现改进的缓存和动态速率限制器以供集群启动所需的资源使用，并定期进行快速替换整个集群的演练，以明确目标为快速且正确的启动。

结论

我们为此次事件给所有客户带来的影响表示歉意——从 ChatGPT 用户到开发者再到依赖 OpenAI 产品的企业。我们没有达到自己的期望。我们认识到向所有客户提供高度可靠的服务至关重要，并将优先实施上述预防措施以继续提高可靠性。感谢大家在此次中断期间的耐心。