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 的底層網路正在承受前所未有的壓力，他們的工程防護網顯然還沒跟上業務膨脹的速度。