OpenAI 最近發布了關於12月11日ChatGPT 和Sora 服務長達4 小時10 分鐘宕機事件的詳細報告。這次事件波及眾多用戶，引起了廣泛關注。報告詳細解釋了故障原因、工程師遇到的困境以及最終恢復服務的整個過程，為其他技術團隊提供了寶貴的經驗教訓。報告中清楚地闡述了故障的根本原因，以及工程師在面對控制面崩潰時採取的一系列應急措施，體現了OpenAI 在突發事件處理上的應對能力。
上週（12月11日）OpenAI 的ChatGPT 和Sora 等服務發生了長達4小時10分鐘的宕機事件，導致許多用戶受到影響。現在，OpenAI正式發布ChatGPT宕機故障詳細報告。
簡單的說這次故障的根本原因是一個小的變更，卻導致了嚴重的後果，工程師們在關鍵時刻被鎖在了控制面之外，無法及時處理問題。對於這次故障，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 操作過載，造成服務癱瘓。
工程師困境:控制面崩潰使得工程師無法訪問，導致無法進行問題處理。
⏳ 恢復過程:透過縮小集群規模和增加資源等手段，最終恢復了服務。
此次事件雖然造成了服務中斷，但也為OpenAI提供了寶貴的經驗，促使他們改善系統架構和緊急計畫，進一步提升服務穩定性，為用戶提供更可靠的服務保障。 相信OpenAI會從這次事件中學到教訓，不斷完善技術，為用戶帶來更好的體驗。