OpenAI最近宕机频繁。上个月，ChatGPT突发故障，导致服务中断近半小时，超过19,000人受到影响。OpenAICEOSamAltman随后在社交媒体X上公开致歉。他表示，公司在可靠性方面比以往有了很大的进步，但仍有许多工作要做。最后他还加了一句：“根据Similarweb的数据，它现在是全球第八大网站”。
OpenAI很快承认问题的存在并着手修复，但仍耗费约三个小时才顺利恢复所有服务。
OpenAI在事后报告中写道，“监控服务覆盖的范围非常广泛，因此这项新服务的配置无意间导致……资源密集的KubernetesAPI操作。我们的KubernetesAPI服务器不堪重负，导致我们的大多数规模Kubernets集群中的控制平面陷入瘫痪。”
OpenAI提到，在客户感受到影响的“几分钟”内，公司就检测到了该问题；但由于必须绕过不堪重负的Kubernetes服务器，因此无法快速实施修复。
该公司写道，“这是多个系统和流程同时发生故障，并以意想不到的方式相互影响的结果。我们的测试未能捕捉到变更对于Kubernetes控制平面的影响，并且由于锁定效应，补救措施的实施非常缓慢。”
OpenAI表示，该公司将采取多项措施防止未来发生类似事件，包括改进登台发布、更好地监控基础设施变化，以及采用新机制以确保OpenAI工程师在任何情况下都能访问公司的KubernetesAPI服务器。
OpenAI自研了基于K8s的管理软件
基础设施团队负责构建和维护了一个复杂而高效的计算环境，以支持研究人员进行实验和开发。这个环境从上到下包括：研究代码、训练算法、各种工具、以及基于TensorFlow和PyTorch等框架的底层基础设施。
为了管理这些复杂的系统，团队使用了内部开发的框架（如Rapid和Rcall）以及开源的框架（如Ray、Kubeflow）。基础设施团队需要负责容器管理和集群调度，而主机和OS的编排则使用的是Chef和Terraform。基础设施需要在多个平台上运行，从Kubernetes到Azure和Google服务器。这意味着我们需要控制平面管理集群，处理回调请求，以及调用一些外部服务如Datadog等工具。
Kubernetes在过去几年中取得了显著进步，现在官方建议的最大集群规模是5000节点，然而，由于Kubernetes的扩展性能无法完全满足OpenAI的需求，基础设施团队于前几年开始开发了一款名为Rapid的框架。
Rapid抽象了平台API，并将虚拟机视为分布在大型机群中的类似pod的单一工作单元，有点像Kubernetespod。
在Rapid的配置中，每个实验都是独立准备和启动的，与其他实验完全隔离，避免共享数据存储来统一写入实验结果。这种高度隔离的设计非常契合研究人员对系统的使用需求，使他们的实验不会因资源竞争或服务中断而受影响，从而可以专注于自己的研究工作。
Rapid框架同时也将大模型训练工作抽象成了三类：部署工作者（rolloutworkers）、优化器（optimizers）和评估工作者（evaluationworkers）。部署工作者负责运行模拟环境，采集观察数据，并将这些样本发送给优化器。优化器是训练模型的核心模块，根据接收到的数据进行参数优化，并生成模型输出。这些输出参数被反馈给部署工作者以完成训练循环，同时被发送给评估工作者，用于判断新版本模型是否优于旧版本。
得益于框架的抽象化设计，OpenAI的基础设施团队在项目进行中能够轻松应对变化。例如，在项目中期，团队抓住机会，将实验从一个云服务提供商迁移到另一个平台，以便获取不同的硬件和不同的容量。为了应对GPU节点频繁维护对训练造成的影响，还需要通过提前检查主机状态，避免将实验部署到即将维护的节点上。
GPT-2则使用了OpenAI研究人员开发的一套名为Rcall框架。这一框架同时支持Kubernetes和云服务后端，使研究人员能够在OpenAI不断扩展的Kubernetes集群中测试和调试任务，随后根据需要迁移到物理机、虚拟机或其他硬件环境。有点像中间派，但是比Rapid更轻量级的抽象，Rapid主要处理整个VM大小。
此次，OpenAI罕见地发布了一份完整的故障报告。我们翻译了原文：
OpenAI故障复盘原文
事件影响
根本原因
OpenAI在全球运营有数百个Kubernetes集群。Kubernetes拥有一个负责集群管理的控制平面，外加实际为模型推理等工作负载提供服务的数据平面。
这些遥测服务的覆盖范围极广，因此新服务的配置无意中使得各个集群中的每个节点均须执行资源密集的KubernetesAPI操作，其成本还会随集群规模而同步扩大。由于数千个节点同时执行这些操作，导致KubernetesAPI服务器不堪重负，进而令大部分规模集群中的Kubernetes控制平面陷入瘫痪。这个问题在我们体量最大的集群中表现最为明显，但由于DNS缓存在该服务的大规模部署之前掩盖了问题，致使我们的测试未能及时发现。
Kubernetes数据平面在很大程度上可以独立于控制平面运行，但DNS依赖于控制平面——具体来讲，各服务无法在缺少Kubernetes控制平面的情况下相互通信。
简言之，引发事故的根本原因就是新的遥测服务配置意外在大规模集群中产生了大量KubernetesAPI负载，导致控制平面不堪重负并破坏了基于DNS的服务发现能力。
测试与部署
Kubernetes数据平台（负责处理用户请求）在设计上能够独立于控制平面运行，但DNS解析仍须借助KubernetesAPI服务器——事实上，DNS解析在我们的许多服务中均属于关键依赖项。
补救措施
监控部署并恢复引发问题的变更一般非常简单，我们有专门的工具以检测并回滚错误部署。在此次事件中，我们的检测工具成功发挥作用，在客户受到实际影响前的几分钟就检测到了问题。但要想解决问题，我们需要删除引发问题的服务，而这要求我们访问Kubernetes控制平面——但随着KubernetesAPI服务器负载的增加，访问操作根本无法进行。
我们在几分钟内就确定了问题，并立即启动了多个工作流，以探索快速恢复集群的不同方法：
通过同时推进这三项工作，我们最终夺回了控制权，得以删除存在问题的服务。
在重新获得对部分Kubernetes控制平面的访问权限之后，恢复工作立即步入了正轨。在可能的情况下，我们尝试将流量转移至健康集群，同时对其他集群进行修复。由于大量服务尝试同时下载资源，资源限制开始饱和并需要额外的手动干预，且部分集群仍处于性能降级状态。
可以看到，此次事件属于多个系统及流程同时发生故障并以意外方式相互影响的结果。具体来讲——
预防措施
为了防止后续再次发生类似事件，我们正着手实施以下举措：
1.稳健的登台发布机制
2.故障注入测试
3.应急Kubernetes控制平面访问
当数据平面对控制平面施加过大压力时，我们应当确保仍可正常访问API服务器。为此我们将实施应急机制，以保证工程师在任何情况下均可访问KubernetesAPI服务器。
4.对Kubernetes数据平面与控制平面进行解耦
我们负责服务发现的KubernetesDNS中的依赖项，导致Kubernetes数据平面与控制平面之间建立了链接。我们正投入资源将Kubernetes数据平面与控制平面相互解耦，借此保证控制平面无需承担处理关键任务服务及产品工作负载等责任。
5.加快恢复速度
我们将为集群启动所必需的资源提供经过改进的缓存及动态速率限制器，同时定期组织演习以保证快速、正确启动目标，实现对整体集群的快速替换。
总结
对于此次事件对全体客户造成的影响，我们深表歉意——包括各位ChatGPT用户、开发人员乃至依赖OpenAI产品的企业。我们未能履行自己的预期与承诺。我们意识到为大家提供高可靠性服务的重要意义，并将着力推动上述预防措施，希望继续提高可靠性。感谢您在此次中断期间的耐心等待。
会议推荐
在AI大模型技术如汹涌浪潮席卷软件开发领域的当下，变革与机遇交织，挑战与突破共生。2025年4月10-12日，QCon全球软件开发大会将在北京召开，以“智能融合，引领未来”为年度主题，汇聚各领域的技术先行者以及创新实践者，为行业发展拨云见日。现在报名可以享受8折优惠，单张门票立省1360元，详情可联系票务经理18514549229咨询。