OpenAI的复盘分析报告，官方原文请见

https://status.openai.com/incidents/ctrsv3lwd797

报告第一段说，这次事故的原因是一个“new telemetry service deployment”把K8S的控制面压垮了。所以导致了OpenAI的大部分服务不可用。

具体原因

K8S有控制平面和数据平面，推理模型当然是在数据平面上。OpenAI说，他们为了改善对集群的可观测性，就部署了一套新系统，也就是上面说的telemetry service。笔者推测是可以对多个集群进行远程数据采集的这么个系统吧。

然后呢，估计是为了去采集数据，这个系统就跑到每个K8S的每个Node上去执行命令。不幸的是这些采集资源的操作，本身估计也挺耗资源。然后几千个节点一起执行。结果导致K8S的控制面扛不住挂了。

当然了，OpenAI说他们新系统上线前也做了测试。但是之前测试环境中DNS有缓存，结果没有测出这个问题。下面一段进一步解释说，DNS是控制面管理的，虽然说业务面和控制面是分开的，但是控制面挂了之后，DNS出问题，所以影响了数据面。而测试时候可能是规模问题没发现这个情况。

而且DNS缓存可以暂时缓解问题，可是20分钟之后，DNS缓存就会过期。然后呢，服务就开始故障了。糟糕的是DNS缓存不能提供服务，反而使得DNS请求更加频繁，于是情况只会恶化起来。

接下来，OpenAI说，他们其实在早期已经通过检测工具发现了问题，然而他们想把有问题的服务隔离出去时，又要使用控制平面。然而前面说了，控制平面现在很忙，不理你了。然后工程师们就只能想办法减少API调用频次，尤其是耗费资源的API调用。然后同时新增一些计算资源来处理请求。当最终资源和API匹配上之后，他们终于可以访问控制面并干掉有问题的服务。

采用这些措施之后，服务逐渐恢复，但是还是花了不少时间。

大致时间线：

12月10日 telemetry service 验证可以按预期运行

2024 年 12 月 11 日下午 2:23，这个新的服务正式部署。

当天2:51 至 3:20：推送到了所有K8S集群

3:13：发现问题并给工程师发了告警

3:16：影响开始出现，同时工程师确定了原因

3:27：工程师试图把流量从受影响集群中干掉

3:40：客户影响达到峰值

4:36：第一个集群恢复了

7:38：所有集群恢复了。

至于这一次的教训，OpenAI表示

1. 分阶段上线

后续要做好分阶段上线，更好地监控所有基础设施变更，以确保任何故障的影响有限并尽早发现。

2. 故障注入测试

K8S 数据平面应该能够在没有控制平面的情况下运行更长时间（也就是对控制面故障注入）。

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

当数据平面对控制平面施加过大压力时，需要确保工程师在任何情况下都有控制权。

4. K8S 数据面和控制面进一步分离

这次事故中，看来K8S的控制面在信息采集时，还是执行了一些高资源占用的业务请求，所以后面OpenAI表示要对此进行控制。=

5. 更快的恢复

其实就是故障演练，这次恢复时间很长主要原因之一是缺乏演练和应急预案。

其实看到这些教训，我不得不提一句。成熟产品的重要标志之一就是，经历和沉淀了太多的教训，并把这些教训定为了规则。

当然了，这是OpenAI的官方分析，也有不少民间分析认为，OpenAI近期一系列的发布，不少是和苹果手机的结合，苹果手机这个庞大的端侧基数是OpenAI没有充分预料的，结果导致了一波流量浪涌带走了OpenAI的服务。我觉得这个判断也是有其道理的，可能是两者相互作用的结果，缺其一也未必会造成这次全面瘫痪。

ITPub博客

OpenAI为啥崩了，官方解读来了

最新文章