↓推薦關注↓
轉自：InfoQ -?核子可樂、Tina
前段時間，OpenAI 旗下 AI 聊天機器人平臺 ChatGPT、視頻生成工具 Sora 及其面向開發人員的 API 自太平洋時間下午 3 點左右起發生嚴重中斷。
OpenAI 最近宕機頻繁。上個月，ChatGPT 突發故障，導致服務中斷近半小時，超過 19,000 人受到影響。OpenAI CEO Sam Altman 隨后在社交媒體 X 上公開致歉。他表示，公司在可靠性方面比以往有了很大的進步，但仍有許多工作要做。最后他還加了一句：“根據 Similarweb 的數據，它現在是全球第八大網站”。
沒想到僅僅一個月時間后，又發生了全球性服務中斷事件。社交媒體上充斥著對 ChatGPT 宕機的各種反應，從玩笑、嘲諷到幽默、惱怒，各種情緒應有盡有。有人夸張的說，全球學術界（留子教育版）倒退了 100 年。還有人調侃說應該試試“祖傳”的電腦維修大法：“你試過關掉再打開嗎？” 另一個用戶則對付費服務無法正常運行感到不滿，“我每月支付 20 美元，卻遇上這種服務中斷的情況，簡直讓人抓狂！”這場“狂歡”背后，也折射出人們對 AI 工具的依賴程度日益加深。
OpenAI 很快承認問題的存在并著手修復，但仍耗費約三個小時才順利恢復所有服務。
在周五發布的一份事后報告中，OpenAI 寫道，此番宕機并非源自安全事件或者近期產品發布，而是因周四部署的用于收集 Kubernetes 指標的監控服務所引發。Kubernetes 是一款開源程序，可幫助管理容器以及在隔離環境下運行軟件的應用程序包與相關文件。
OpenAI 在事后報告中寫道，“監控服務覆蓋的范圍非常廣泛，因此這項新服務的配置無意間導致……資源密集的 Kubernetes API 操作。我們的 Kubernetes API 服務器不堪重負，導致我們的大多數規模 Kubernets 集群中的控制平面陷入癱瘓。”
OpenAI 提到，在客戶感受到影響的“幾分鐘”內，公司就檢測到了該問題；但由于必須繞過不堪重負的 Kubernetes 服務器，因此無法快速實施修復。
該公司寫道，“這是多個系統和流程同時發生故障，并以意想不到的方式相互影響的結果。我們的測試未能捕捉到變更對于 Kubernetes 控制平面的影響，并且由于鎖定效應，補救措施的實施非常緩慢。”
OpenAI 表示，該公司將采取多項措施防止未來發生類似事件，包括改進登臺發布、更好地監控基礎設施變化，以及采用新機制以確保 OpenAI 工程師在任何情況下都能訪問公司的 Kubernetes API 服務器。
OpenAI 自研了基于 K8s 的管理軟件
他們負責構建和維護一個復雜而高效的計算環境，以支持研究人員進行實驗和開發。這個環境從上到下包括：研究代碼、訓練算法、各種工具、以及基于 TensorFlow 和 PyTorch 等框架的底層基礎設施。
為了管理這些復雜的系統，團隊使用了內部開發的框架（如 Rapid 和 Rcall）以及開源的框架（如 Ray、Kubeflow）。基礎設施團隊需要負責容器管理和集群調度，而主機和 OS 的編排則使用的是 Chef 和 Terraform。基礎設施需要在多個平臺上運行，從 Kubernetes 到 Azure 和 Google 服務器。這意味著我們需要控制平面管理集群，處理回調請求，以及調用一些外部服務如 Datadog 等工具。
從堆棧描述中我們可以看出，基礎設施團隊實際上幫助調試和管理了幾乎所有內容，確保與研究相關的工作順利進行。
Kubernetes 在過去幾年中取得了顯著進步，現在官方建議的最大集群規模是 5000 節點，然而，由于 Kubernetes 的擴展性能無法完全滿足 OpenAI 的需求，基礎設施團隊于前幾年開始開發了一款名為 Rapid 的框架。
Rapid 抽象了平臺 API，并將虛擬機視為分布在大型機群中的類似 pod 的單一工作單元，有點像 Kubernetes pod。
在 Rapid 的配置中，每個實驗都是獨立準備和啟動的，與其他實驗完全隔離，避免共享數據存儲來統一寫入實驗結果。這種高度隔離的設計非常契合研究人員對系統的使用需求，使他們的實驗不會因資源競爭或服務中斷而受影響，從而可以專注于自己的研究工作。
Rapid 框架同時也將大模型訓練工作抽象成了三類：部署工作者（rollout workers）、優化器（optimizers） 和評估工作者（evaluation workers）。部署工作者負責運行模擬環境，采集觀察數據，并將這些樣本發送給優化器。優化器是訓練模型的核心模塊，根據接收到的數據進行參數優化，并生成模型輸出。這些輸出參數被反饋給部署工作者以完成訓練循環，同時被發送給評估工作者，用于判斷新版本模型是否優于舊版本。
得益于框架的抽象化設計，OpenAI 的基礎設施團隊在項目進行中能夠輕松應對變化。例如，在項目中期，團隊抓住機會，將實驗從一個云服務提供商遷移到另一個平臺，以便獲取不同的硬件和不同的容量。為了應對 GPU 節點頻繁維護對訓練造成的影響，還需要通過提前檢查主機狀態，避免將實驗部署到即將維護的節點上。
GPT-2 則使用了 OpenAI 研究人員開發的一套名為 Rcall 框架。這一框架同時支持 Kubernetes 和云服務后端，使研究人員能夠在 OpenAI 不斷擴展的 Kubernetes 集群中測試和調試任務，隨后根據需要遷移到裸金屬虛擬機或其他硬件環境。有點像中間派，但是比 Rapid 更輕量級的抽象，Rapid 主要處理整個 VM 大小。
2021 年，在訓練 GPT-3 時，OpenAI 已經能管理 7500 個節點，并表示他們不太依賴 Kubernetes 的負載均衡，同時他們放棄 Flannel 組件轉而使用 Azure VMSS 的本地 Pod 網絡技術和相關 CNI 插件來配置 IP。此外，OpenAI 還使用 Prometheus 收集大量指標數據，并使用 Grafana 進行圖形、儀表板和警報。
另外，隨著研究實驗的復雜性不斷增加，快速定位問題一直是個大挑戰。尤其是當實驗失敗時，研究人員往往需要花費大量時間去翻閱日志（在 DataDog 中）。為了提高問題排查效率，OpenAI 的基礎設施團隊不斷的開發監控相關的軟件，滿足各種不同的查詢要求，比如輸入簡單的查詢，比如“為什么這個 pod 失敗了”，研究人員就能快速得到詳細的故障原因分析，例如“該 pod 所在的主機因維護事件被移除”。
而本周的這次故障，直接原因是他們又新部署了一套監控系統，導致 Kubernetes 控制面臨的負擔加重。隨后，由于控制面的故障（依賴于 DNS 和 K8S），無法直接回滾此次發布，進一步放大了故障影響，導致長時間不可用。
此次，OpenAI 罕見地發布了一份完整的故障報告。我們翻譯了原文：
OpenAI 故障復盤原文
此份事后分析報告，詳細回顧了 2024 年 12 月 11 日發生的一起意外事故，OpenAI 旗下所有服務均經歷長時間宕機。該問題源自新部署的遙測服務，此項服務無意間壓垮了 Kubernetes 控制平面，導致關鍵系統發生連鎖故障。在這篇文章中，我們將分析其根本原因，概述補救措施、分享后續防范方案以避免類似事件再次重演。
2024 年 12 月 11 是太平洋標準時間下午 3：16 至晚 7：38 之間，所有 OpenAI 服務均經歷了嚴重降級甚至完全不可用。此次事件源自在整個產品組合中推出新的遙測服務這一重大變更所引發，與安全事件或近期發布的新產品無關。所有產品均于下午 3：16 開始遭遇降級。
ChatGPT：下午 5：45 服務基本恢復，太平洋標準時間下午 7：01 完全恢復。
API：下午 5：36 服務基本恢復，太平洋標準時間下午 7：38 所有模型均已恢復。
Sora：太平洋標準時間下午 7：01 完全恢復。
OpenAI 在全球運營有數百個 Kubernetes 集群。Kubernetes 擁有一個負責集群管理的控制平面，外加實際為模型推理等工作負載提供服務的數據平面。
作為提高組織整體可靠性的保障性舉措的一部分，我們一直在努力改進自身集群范圍內的可觀察性工具，以增強我們系統狀態的可見性。太平洋標準時間下午 3：12，我們部署了一項新的遙測服務用以收集 Kubernetes 控制平面的詳細指標。
這些遙測服務的覆蓋范圍極廣，因此新服務的配置無意中使得各個集群中的每個節點均須執行資源密集的 Kubernetes API 操作，其成本還會隨集群規模而同步擴大。由于數千個節點同時執行這些操作，導致 Kubernetes API 服務器不堪重負，進而令大部分規模集群中的 Kubernetes 控制平面陷入癱瘓。這個問題在我們體量最大的集群中表現最為明顯，但由于 DNS 緩存在該服務的大規模部署之前掩蓋了問題，致使我們的測試未能及時發現。
Kubernetes 數據平面在很大程度上可以獨立于控制平面運行，但 DNS 依賴于控制平面——具體來講，各服務無法在缺少 Kubernetes 控制平面的情況下相互通信。
簡言之，引發事故的根本原因就是新的遙測服務配置意外在大規模集群中產生了大量 Kubernetes API 負載，導致控制平面不堪重負并破壞了基于 DNS 的服務發現能力。
此番變更在登臺集群內進行了測試，但沒有觀察到任何問題。只有規模超過一定水平的集群才會受到影響，而我們各個節點上的 DNS 緩存則大大延后了故障被觀察到的時間，因此部署工作仍在如常推進。
部署之前，我們最關注的可靠性問題就是新遙測服務的資源消耗。在部署之前，我們評估了所有集群（CPU/ 內存）方面的資源利用率指標，以確保部署不會中斷正在運行的服務。盡管資源請求會按集群進行調整，但我們沒有采取任何預防措施來評估 Kubernetes API 服務器負載。另外，部署流程雖然會監控服務運行狀況，但未充分配備集群運行狀況監控協議。
Kubernetes 數據平臺（負責處理用戶請求）在設計上能夠獨立于控制平面運行，但 DNS 解析仍須借助 Kubernetes API 服務器——事實上，DNS 解析在我們的許多服務中均屬于關鍵依賴項。
DNS 緩存能夠提供過時但可正常運行的 DNS 記錄，也正是這項功能緩解了性能影響。然而，隨著緩存記錄在接下來的 20 分鐘內過期，服務實時 DNS 解析的服務開始出現故障。這個時間窗口至關重要，因為其延后了問題被發現的時間，導致我們在未了解問題全貌之前繼續推進部署。當 DNS 緩存為空之后，DNS 服務器上的負載開始成倍增加，這進一步增加了控制平面的負載，也大大增加了即時緩解工作的實施難度。
監控部署并恢復引發問題的變更一般非常簡單，我們有專門的工具以檢測并回滾錯誤部署。在此次事件中，我們的檢測工具成功發揮作用，在客戶受到實際影響前的幾分鐘就檢測到了問題。但要想解決問題，我們需要刪除引發問題的服務，而這要求我們訪問 Kubernetes 控制平面——但隨著 Kubernetes API 服務器負載的增加，訪問操作根本無法進行。
我們在幾分鐘內就確定了問題，并立即啟動了多個工作流，以探索快速恢復集群的不同方法：
縮小集群規模：降低總 Kubernetes API 負載。
阻止對 Kubernetes 管理員 API 的網絡訪問：阻止新的高資源成本請求，讓 API 服務器有時間恢復正常。
擴展 Kubernetes API 服務器：增加可用資源以消化待處理請求，借此為修復操作留出空間。
通過同時推進這三項工作，我們最終奪回了控制權，得以刪除存在問題的服務。
在重新獲得對部分 Kubernetes 控制平面的訪問權限之后，恢復工作立即步入了正軌。
在可能的情況下，我們嘗試將流量轉移至健康集群，同時對其他 集群進行修復。由于大量服務嘗試同時下載資源，資源限制開始飽和并需要額外的手動干預，且部分集群仍處于性能降級狀態。
可以看到，此次事件屬于多個系統及流程同時發生故障并以意外方式相互影響的結果。具體來講——
我們的測試未能捕捉到變更對于 Kubernetes 控制平面的影響。
DNS 緩存的存在，延長了執行變更及服務開始發生故障之間的間隔。
由于鎖定效應，補救措施推進緩慢。
2024 年 12 月 10 日：新的遙測服務被部署至登臺集群，并在驗證流程中符合預期。
2024 年 12 月 11 日下午 2：23：引入新服務的變更被納入部署管線并開始執行。
下午 2：51 至 3：20：變更被應用于所有集群。
下午 3：13：發出警報，通知工程師。
下午 3：16：開始對客戶產生輕微影響。
下午 3：16：確定根本原因。
下午 3：27：工程師開始將流量從受影響的集群中移出。
下午 3：40：對客戶的影響達到峰值。
下午 4：36：首個集群成功恢復。
下午 7：38：所有集群均已恢復。
為了防止后續再次發生類似事件，我們正著手實施以下舉措：
我們將繼續改進登臺發布機制，更好地監控所有基礎設施的變化，以確保任何故障均不會造成太大影響且可被及早發現。今后一切與基礎設施相關的配置變更，都將遵循穩健的登臺發布流程；同時持續監控機制也將得到改進，確保服務工作負載和集群（包括 Kubernetes 控制平面）始終健康。
Kubernetes 數據平面應可在控制平面中斷的情況下運行更長時間，我們也將明確針對這類情況運行測試。我們還將在測試中涵蓋惡意變更狀況，確保我們的系統能夠檢測到問題并適時回滾。
當數據平面對控制平面施加過大壓力時，我們應當確保仍可正常訪問 API 服務器。為此我們將實施應急機制，以保證工程師在任何情況下均可訪問 Kubernetes API 服務器。
我們負責服務發現的 Kubernetes DNS 中的依賴項，導致 Kubernetes 數據平面與控制平面之間建立了鏈接。我們正投入資源將 Kubernetes 數據平面與控制平面相互解耦，借此保證控制平面無需承擔處理關鍵任務服務及產品工作負載等責任。
我們將為集群啟動所必需的資源提供經過改進的緩存及動態速率限制器，同時定期組織演習以保證快速、正確啟動目標，實現對整體集群的快速替換。
對于此次事件對全體客戶造成的影響，我們深表歉意——包括各位 ChatGPT 用戶、開發人員乃至依賴 OpenAI 產品的企業。我們未能履行自己的預期與承諾。我們意識到為大家提供高可靠性服務的重要意義，并將著力推動上述預防措施，希望繼續提高可靠性。感謝您在此次中斷期間的耐心等待。
參考鏈接：
https://techcrunch.com/2024/12/13/openai-blames-its-massive-chatgpt-outage-on-a-new-telemetry-service/
https://www.infoq.cn/article/g9tuotodp20n1ltzjsjw
https://www.datadoghq.com/videos/scaling-ai-infra/
https://status.openai.com/incidents/ctrsv3lwd797
—— EOF —— 你好，我是飛宇。日常分享C/C++、計算機學習經驗、工作體會，歡迎點擊此處查看我以前的學習筆記&經驗&分享的資源。
我組建了一些社群一起交流，群里有大牛也有小白，如果你有意可以一起進群交流。
歡迎你添加我的微信，我拉你進技術交流群。此外，我也會經常在微信上分享一些計算機學習經驗以及工作體驗，還有一些內推機會。
加個微信，打開另一扇窗
經常遇到有讀者后臺私信想要一些編程學習資源，這里分享 1T 的編程電子書、C/C++開發手冊、Github上182K+的架構路線圖、LeetCode算法刷題筆記等精品學習資料，點擊下方公眾號會回復"編程"即可免費領取~
感謝你的分享，點贊，在看三連??
