譯者 | 李睿

審校 | 重樓

2024年12月11日， OpenAI公司提供的服務(wù)由于新部署的遙測服務(wù)出現(xiàn)問題而遭遇重大停機。此次事件影響了API、ChatGPT和Sora服務(wù)，導(dǎo)致持續(xù)數(shù)小時的服務(wù)中斷。作為一家致力于提供準確高效的人工智能解決方案的供應(yīng)商，OpenAI公司為此發(fā)布一份詳細的事后分析報告，公開地討論了出現(xiàn)問題的原因，以及他們?nèi)绾斡媱澐乐乖谖磥戆l(fā)生類似事件。

本文將闡述此次事件的技術(shù)細節(jié)，分析根本原因，并探討開發(fā)人員和管理分布式系統(tǒng)的組織可以從此次事件中吸取的關(guān)鍵教訓(xùn)。

事件時間線

以下是OpenAI公司在2024年12月11日發(fā)生停機事件的快照：

圖1 ：OpenAI的停機事件時間線——服務(wù)降級到完全恢復(fù)

事件的根本原因分析

事件的根源在于美國太平洋標準時間（PST）12月11日下午3:12部署的一個新的遙測服務(wù)，以提高Kubernetes控制平臺的可觀察性。然而，該服務(wù)意外地使多個集群的Kubernetes API服務(wù)器過載從而導(dǎo)致級聯(lián)故障。

詳細解析

（1）遙測服務(wù)部署

遙測服務(wù)旨在收集詳細的Kubernetes控制平臺指標，但其配置不當觸發(fā)了跨數(shù)千個節(jié)點同時進行的資源密集型Kubernetes API操作。

（2）控制平臺過載

負責集群管理的Kubernetes控制平臺不堪重負。雖然處理用戶請求的數(shù)據(jù)平臺仍保持部分功能，但它依賴于控制平臺進行DNS解析。隨著緩存的DNS記錄過期，依賴實時DNS解析的服務(wù)開始出現(xiàn)故障。

（3）測試不足

該部署在測試環(huán)境中進行了測試，但測試集群的規(guī)模并未模擬生產(chǎn)集群的規(guī)模。因此，在測試期間未檢測到API服務(wù)器負載問題。

如何緩解問題

當事件發(fā)生時，OpenAI的工程師很快確定了根本原因，但由于Kubernetes控制平臺超載，無法訪問API服務(wù)器，因此在實施修復(fù)時面臨一些挑戰(zhàn)。他們采取了多管齊下的辦法：

• 縮小集群規(guī)模：減少每個集群中的節(jié)點數(shù)量可以降低API服務(wù)器負載。
• 阻止網(wǎng)絡(luò)訪問Kubernetes管理API：阻止額外的API請求，允許服務(wù)器恢復(fù)。
• 擴展Kubernetes API服務(wù)器：配置額外的資源有助于清除掛起的請求。

這些措施使工程師能夠重新獲得對控制平臺的訪問權(quán)限，并消除有問題的遙測服務(wù)，從而恢復(fù)服務(wù)功能。

經(jīng)驗教訓(xùn)

此次事件凸顯了在分布式系統(tǒng)中進行健壯測試、監(jiān)控和故障安全機制的重要性。以下是OpenAI從停機事件吸取（并實施）的經(jīng)驗和教訓(xùn)：

1.穩(wěn)健的分階段推出

現(xiàn)在，所有基礎(chǔ)設(shè)施更改都將遵循分階段推出，并進行持續(xù)監(jiān)控。這可以確保問題在擴展到整個系統(tǒng)之前及早發(fā)現(xiàn)并緩解問題。

2.故障注入測試

通過模擬故障（例如，禁用控制平臺或推出糟糕的更改），OpenAI公司將驗證他們的系統(tǒng)可以自動恢復(fù)并在影響客戶之前檢測問題。

3.應(yīng)急控制平臺訪問

“緊急訪問”（break-glass）機制將確保工程師即使在高負載下也能訪問Kubernetes API服務(wù)器。

4.解耦控制與數(shù)據(jù)平臺

為了減少依賴，OpenAI公司將Kubernetes數(shù)據(jù)平臺（處理工作負載）與控制平臺（負責編排）解耦，確保關(guān)鍵服務(wù)即使在控制平臺中斷時也能繼續(xù)運行。

5.更快的恢復(fù)機制

新的緩存和速率限制策略將改進集群啟動時間，確保在故障期間更快地恢復(fù)。

示例代碼：分階段推出示例

下面是一個使用Helm和Prometheus實現(xiàn)Kubernetes分階段推出的示例。

分階段推出的Helm部署：

Shell 
 # Deploy the telemetry service to 10% of clusters
 helm upgrade --install telemetry-service ./telemetry-chart \
 --set replicaCount=10 \
 --set deploymentStrategy=phased-rollout

用于監(jiān)控API服務(wù)器負載的Prometheus查詢：

YAML 
 # PromQL Query to monitor Kubernetes API server load
 sum(rate(apiserver_request_duration_seconds_sum[1m])) by (cluster) / 
 sum(rate(apiserver_request_duration_seconds_count[1m])) by (cluster)

這一查詢有助于跟蹤API服務(wù)器請求的響應(yīng)時間，確保及早發(fā)現(xiàn)負載峰值。

故障注入示例

使用混沌網(wǎng)格，OpenAI可以模擬網(wǎng)絡(luò)中斷。

Shell 
 # Inject fault into Kubernetes API server to simulate downtime
 kubectl create -f api-server-fault.yaml

api-server-fault.yaml：

YAML 
 apiVersion: chaos-mesh.org/v1alpha1
 kind: PodChaos
 metadata:
 name: api-server-fault
 spec:
 action: pod-kill
 mode: one
 selector:
 namespaces:
 - kube-system
 labelSelectors:
 app: kube-apiserver

這一配置旨在通過故意終止API服務(wù)器Pod來驗證系統(tǒng)的恢復(fù)能力。

這次事件的重要意義

這一事件凸顯了設(shè)計彈性系統(tǒng)和采用嚴格測試方法的重要性，無論是在大規(guī)模管理分布式系統(tǒng)，還是在工作負載實施Kubernetes。以下是值得借鑒的幾個要點：

• 定期模擬故障：使用混沌工程工具（如 Chaos Mesh）在真實環(huán)境下測試系統(tǒng)的魯棒性。
• 多層級監(jiān)視：確保可觀察性堆棧同時跟蹤服務(wù)級別指標和集群健康指標。
• 解耦關(guān)鍵依賴關(guān)系：減少對單點故障的依賴，例如基于DNS的服務(wù)發(fā)現(xiàn)。

結(jié)論

雖然并沒有任何系統(tǒng)能夠免受故障影響，但像這樣的事件再次提醒我們，透明度、快速補救和持續(xù)學(xué)習至關(guān)重要。OpenAI公司主動分享這一事后分析的方法，為其他組織提供了改善其運營實踐和可靠性的藍圖。

通過優(yōu)先考慮穩(wěn)健的分階段部署、故障注入測試和彈性系統(tǒng)設(shè)計，OpenAI公司為如何處理和從大規(guī)模中斷中學(xué)習樹立了一個典范。

對于管理分布式系統(tǒng)的團隊來說，這個事件是一個很好的案例借鑒，可以用來研究如何進行風險管理和最大限度地減少核心業(yè)務(wù)流程的停機時間。

希望我們以此為契機，共同構(gòu)建更好、更有彈性的系統(tǒng)。

原文標題：How OpenAI’s Downtime Incident Teaches Us to Build More Resilient Systems，作者：Vasanthi Govindaraj