OpenAI 史上最长宕机：自研 K8s 成“拦路虎”，导致数小时无法修复

OpenAI提到，在客户感受到影响的“几分钟”内，公司就检测到了该问题；但由于必须绕过不堪重负的Kubernetes服务器，因此无法快速实施修复。

原标题：OpenAI 史上最长宕机：自研 K8s 成“拦路虎”，导致数小时无法修复
文章来源：AI前线
内容字数：11311字

OpenAI大规模服务中断深度解析

本文总结了OpenAI于2024年12月11日发生的全球中断，详细分析其原因、影响、补救措施及未来预防方案。

1. 概述及影响

2024年12月11日下午3点左右，OpenAI旗下ChatGPT、Sora以及API服务均出现严重中断，持续约三个小时。此次波及全球用户，对ChatGPT、API和Sora等所有服务造成严重影响，严重程度在下午3点40分达到峰值。OpenAI在事后发布了详细的故障报告，承认此次宕机并非安全或新产品发布引起。

2. 根本原因分析

根本原因在于新部署的用于收集Kubernetes指标的监控服务配置错误。该服务覆盖范围极广，导致数千个节点同时执行资源密集型Kubernetes API操作，最终压垮了Kubernetes API服务器，使大部分集群的控制平面瘫痪。DNS依赖于控制平面，服务之间无法通信，进一步加剧了故障影响。虽然在登台环境中测试未发现问题，但大规模集群及DNS缓存延缓了故障的发现。

3. 测试与部署问题

OpenAI在登台集群中测试了新服务，但未发现问题。大规模集群才暴露了问题，DNS缓存也掩盖了问题，导致部署继续进行。部署前，OpenAI关注资源消耗，但未评估Kubernetes API服务器负载，监控流程也未充分配备集群运行状况监控协议。DNS缓存延缓了问题发现时间，加剧了故障影响。

4. 补救措施及时间线

OpenAI在几分钟内确定问题，并采取了缩小集群规模、阻止对Kubernetes管理员API的网络访问以及扩展Kubernetes API服务器等措施。在恢复部分控制平面访问权限后，恢复工作迅速进行，但由于资源限制和部分集群性能降级，仍需额外手动干预。整个恢复过程历时约四个小时。

5. 未来预防措施

为避免类似再次发生，OpenAI将采取以下措施：改进登台发布机制，增强基础设施变化监控；进行故障注入测试，确保系统能检测并回滚问题；实施应急机制，保证工程师在任何情况下都能访问Kubernetes API服务器；解耦Kubernetes数据平面和控制平面；加快恢复速度，改进缓存和动态速率限制器。

6. OpenAI内部技术架构

OpenAI拥有复杂的计算环境，使用了自研框架Rapid和Rcall以及开源框架如Ray、Kubeflow等。Rapid抽象了平台API，将虚拟机视为工作单元，提高了实验隔离性；Rcall则支持Kubernetes和云服务后端，方便研究人员测试和调试任务。OpenAI还使用Prometheus和Grafana进行监控和告警。

7. 总结

OpenAI此次大规模服务中断暴露了其基础设施管理中的不足，也促使其反思并改进相关流程和技术。OpenAI承诺将改进其可靠性，避免类似再次发生，并为用户带来的不便表示歉意。

联系作者

文章来源：AI前线
作者微信：
作者简介：面向AI爱好者、开发者和科学家，提供大模型最新资讯、AI技术分享干货、一线业界实践案例，助你全面拥抱AIGC。