上週（12月11日）OpenAI 的 ChatGPT 和 Sora 等服務發生了長達4小時10分鐘的宕機事件，導致衆多用戶受到影響。現在，OpenAI正式發佈ChatGPT宕機故障詳細報告。

image.png

簡單的說這次故障的根本原因是一個小的變更，卻導致了嚴重的後果，工程師們在關鍵時刻被鎖在了控制面之外，無法及時處理問題。對於此次故障，OpenAI 的工程師在發現問題後迅速展開了多項修復工作，包括縮減集羣規模、阻止對 Kubernetes 管理 API 的網絡訪問以及增加 Kubernetes API 服務器的資源。經過幾輪努力，工程師們終於恢復了對部分 Kubernetes 控制平面的訪問，並採取措施將流量轉移到健康的集羣中，最終實現了系統的全面恢復。

事故發生在太平洋標準時間下午3點12分，工程師們爲收集 Kubernetes（K8S）控制面指標而部署了新的遙測服務。然而，由於該服務的配置無意間過於廣泛，導致每個集羣中的每個節點同時執行資源密集型的 K8S API 操作。這一情況迅速造成了 API 服務器的崩潰，從而使得大多數集羣的 K8S 數據面失去了服務能力。

值得注意的是，雖然 K8S 數據面在理論上可以獨立於控制面運行，但 DNS 的功能依賴於控制面，這使得服務之間無法相互聯繫。當 API 操作過載時，服務發現機制受損，導致了整個服務的癱瘓。雖然問題在3分鐘內就被定位，但由於工程師無法訪問控制面進行服務回滾，導致了一個 “死循環” 局面。控制面崩潰使得他們無法刪除有問題的服務，進而無法進行恢復。

OpenAI 工程師們隨即開始探索恢復集羣的不同方法。他們嘗試縮小集羣規模以減少 K8S 的 API 負載，並阻止對管理 K8S API 的訪問，以便服務器可以恢復正常運轉。此外，他們還擴大了 K8S API 服務器的資源配置，以便更好地處理請求。經過一系列努力，工程師們終於重新獲得了對 K8S 控制面的控制，得以刪除故障服務並逐步恢復集羣。

在此期間，工程師們還將流量轉移到已恢復或新增的健康集羣中，以降低其他集羣的負載。然而，由於許多服務試圖同時恢復，導致資源限制飽和，恢復過程需要額外的手動干預，部分集羣恢復耗時較長。通過這次事故，OpenAI 有望總結經驗，避免在未來遇到類似情況時再次被 “鎖門”。

報告詳情:https://status.openai.com/incidents/ctrsv3lwd797

劃重點:  

🔧 故障原因:小的遙測服務變更導致 K8S API 操作過載，造成服務癱瘓。  

🚪 工程師困境:控制面崩潰使得工程師無法訪問，導致無法進行問題處理。  

⏳ 恢復過程:通過縮小集羣規模和增加資源等手段，最終恢復了服務。