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。