ChatGPT 遭遇史上最长大宕机，OpenAI 归咎于新遥测服务

如果你在周三下午发现 ChatGPT 突然不理人了，或者 API 一直报错，别怀疑，不是你家路由器的问题。

当时 OpenAI 经历了公司历史上持续时间最长的一场大宕机。包括 ChatGPT、视频生成工具 Sora 以及面向开发者的 API 服务全部瘫痪，持续了将近三个小时才完全恢复。

大家一开始还在猜是不是又被黑客打了，或者新模型上线把服务器挤爆了。但 OpenAI 随后发布的事后复盘报告却给出了一个让人哭笑不得的答案：罪魁祸首既不是外部攻击，也不是产品迭代，而是一个用来监控系统指标的新服务。

监控软件把自己人给「误杀」了

说白了，OpenAI 在周三部署了一套新的遥测服务，专门用来收集 Kubernetes 的运行指标。Kubernetes 是管理软件容器的基础系统，支撑着 OpenAI 庞大的底层架构。

问题在于，这种遥测服务的监控范围非常广。新服务的配置出了差错，在无意中发起了海量极度消耗资源的 Kubernetes API 请求。

这一波内部流量直接把自己的 Kubernetes API 服务器给冲垮了，导致大多数大型集群的控制平面瞬间瘫痪。

更要命的是连锁反应。底层集群一崩溃，直接影响到了 OpenAI 各项服务赖以生存的 DNS 域名解析功能。

而原本用来加速访问的 DNS 缓存机制，这次反而帮了倒忙。缓存延缓了故障的暴露，让工程师误以为一切正常，导致这个致命的新服务继续推向了更多节点，直到全面失控。

工程师被锁在门外三小时

其实在普通用户察觉到异样之前的几分钟，OpenAI 的系统就已经发出了警报。但发现问题和能修好是两码事。

OpenAI 在复盘中承认，这是一次多个系统和流程同时失效且互相影响的连环车祸。他们的测试环节完全没测出这个改动会对控制平面造成这么大冲击。

由于 Kubernetes 服务器已经彻底过载，工程师们甚至遇到了类似「把自己锁在门外」的窘境。他们无法直接连上服务器去修复，只能绕着弯子慢慢排查，硬生生花了三个小时才把所有服务拉起来。

OpenAI 随后向所有用户、开发者和企业客户道歉，承认这次表现远低于自己的预期。他们承诺之后会改进基础设施的分阶段发布流程，并建立一套新机制，确保工程师在任何极端情况下都能连上底层的 API 服务器。

为什么重要

这场长达三小时的停摆，给所有把业务押在单一 AI 接口上的团队结结实实提了个醒。

对开发者和企业来说，现在依赖单一模型供应商的风险已经高到了不可忽视的地步。如果你的核心产品几小时打不开，用户不会管是 OpenAI 的遥测服务崩了还是你的代码崩了。现在非常值得做的事情，就是在架构层做好多模型兜底，至少在 OpenAI 宕机时能无缝切到其他备用接口。

对整个行业而言，这次事故暴露了一个非常典型的架构痛点：AI 基础设施的规模扩张得太快，传统的运维与监控工具反而成了最脆弱的短板。监控工具本身产生的高负载反噬了主系统，这种低级配置错误出现在头部的 AI 巨头身上，听起来有点讽刺。

我们认为，OpenAI 在事后复盘中公开这些细节的态度值得认可，至少没有用语焉不详的借口敷衍。但这也清楚地表明，随着 Sora 等高算力产品的加入，OpenAI 的底层网络正在承受前所未有的压力，他们的工程防护网显然还没跟上业务膨胀的速度。