OpenAI發布12月11日ChatGPT宕機故障報告：叢集出現死循環把工程師擋在門外
12 月11 日OpenAI ChatGPT 和Sora 等服務出現長達4 小時10 分鐘的宕機，此次宕機只是個小更改導致的，而且這個小更改僅在部署3 分鐘後就被發現出現問題，按理說這麼快發現問題應該是很容易解決的。
不過OpenAI 也出現了和某些公司相同的錯誤：服務掛了後把工程師也給鎖門外了，也就是工程師無法正常連接控制面進行問題處理。
OpenAI 採用的後端服務架構：
OpenAI 的後端服務都運行在全球數百個Kubernetes 叢集中，其中有個負責叢集管理的控制面和和資料面，OpenAI 向使用者提供服務的是K8S 資料面。
接下來是事故大概：
12 月11 日太平洋標準時間下午3:12，工程師部署新的遙測服務來收集K8S 控制面指標，由於遙測服務覆蓋範圍非常廣，因此這個新服務配置無意中導致每個集群上的每個節點都執行資源密集型的K8S API 操作。
由於數千個節點同時執行資源密集的APi 操作，導致API 伺服器不堪重負而宕機，這導致大多數叢集中的K8S 資料面癱瘓無法再提供服務。
K8S 資料面很大程度上確實可以獨立於控制面運行，但DNS 依賴控制面，如果沒有K8S 控制面，那麼服務就不知道如何相互聯繫。
而不堪重負的API 操作破壞了基於DNS 的服務發現，也就是導致服務無法相互連接，那為什麼3 分鐘就成功定位問題但要花費大量時間才能解決呢？
原因在於要回滾剛剛的遙測服務需要先到K8S 控制面上把舊服務刪除，但現在控制面已經掛了因此工程師們也無法成功連接，這就造成了死循環，這種死循環在其他公司的事故中也挺常見，沒想到OpenAI 也有類似的問題。
最終的處理方式：
OpenAI 工程師探索快速恢復叢集的不同方法，包括縮小叢集規模減少對K8S 的API 負載、阻止對用於管理的K8S API 存取讓伺服器能夠恢復、擴大K8S API 伺服器增加可用資源來處理請求。
最後這三項工作同時進行讓工程師們重新獲得控制權，也就是能夠重新連接K8S 控制面並刪除有問題的服務，一旦重新連接就可以回滾遙測服務更改逐漸恢復集群。
期間工程師們還將流量轉移到已經恢復的叢集或新增的健康的叢集中，這樣繼續降低其他問題叢集的負載然後進行處理，但由於許多服務試圖同時下載資源導致資源限制飽和和並需要額外的手動幹預，因此一些集群花費了大量時間才完成恢復。
經過這次事故相信OpenAI 應該可以學到解決死循環問題，至少下次再發生類似情況是可以快速連線解決問題，而不是將工程師鎖在門外。