OpenAI的停机事件教会我们要构建更具弹性的系统-51CTO.COM

译者 | 李睿

审校 | 重楼

2024年12月11日， OpenAI公司提供的服务由于新部署的遥测服务出现问题而遭遇重大停机。此次事件影响了API、ChatGPT和Sora服务，导致持续数小时的服务中断。作为一家致力于提供准确高效的人工智能解决方案的供应商，OpenAI公司为此发布一份详细的事后分析报告，公开地讨论了出现问题的原因，以及他们如何计划防止在未来发生类似事件。

本文将阐述此次事件的技术细节，分析根本原因，并探讨开发人员和管理分布式系统的组织可以从此次事件中吸取的关键教训。

事件时间线

以下是OpenAI公司在2024年12月11日发生停机事件的快照：

时间 (PST)	事件
3:16PM	开始对客户产生轻微影响；观察到服务降级
3:27PM	工程师开始重定向受影响集群的流量
3:40PM	记录的最大客户影响；所有服务的重大中断
4:36PM	第一个Kubernetes集群开始恢复
5:36PM	API服务开始大幅复苏
5:45PM	观察到ChatGPT大幅恢复
7:38PM	所有集群中的所有服务均已经完全恢复

图1 ：OpenAI的停机事件时间线——服务降级到完全恢复

事件的根本原因分析

事件的根源在于美国太平洋标准时间（PST）12月11日下午3:12部署的一个新的遥测服务，以提高Kubernetes控制平台的可观察性。然而，该服务意外地使多个集群的Kubernetes API服务器过载从而导致级联故障。

详细解析

（1）遥测服务部署

遥测服务旨在收集详细的Kubernetes控制平台指标，但其配置不当触发了跨数千个节点同时进行的资源密集型Kubernetes API操作。

（2）控制平台过载

负责集群管理的Kubernetes控制平台不堪重负。虽然处理用户请求的数据平台仍保持部分功能，但它依赖于控制平台进行DNS解析。随着缓存的DNS记录过期，依赖实时DNS解析的服务开始出现故障。

（3）测试不足

该部署在测试环境中进行了测试，但测试集群的规模并未模拟生产集群的规模。因此，在测试期间未检测到API服务器负载问题。

如何缓解问题

当事件发生时，OpenAI的工程师很快确定了根本原因，但由于Kubernetes控制平台超载，无法访问API服务器，因此在实施修复时面临一些挑战。他们采取了多管齐下的办法：

缩小集群规模：减少每个集群中的节点数量可以降低API服务器负载。
阻止网络访问Kubernetes管理API：阻止额外的API请求，允许服务器恢复。
扩展Kubernetes API服务器：配置额外的资源有助于清除挂起的请求。

这些措施使工程师能够重新获得对控制平台的访问权限，并消除有问题的遥测服务，从而恢复服务功能。

经验教训

此次事件凸显了在分布式系统中进行健壮测试、监控和故障安全机制的重要性。以下是OpenAI从停机事件吸取（并实施）的经验和教训：

1.稳健的分阶段推出

现在，所有基础设施更改都将遵循分阶段推出，并进行持续监控。这可以确保问题在扩展到整个系统之前及早发现并缓解问题。

2.故障注入测试

通过模拟故障（例如，禁用控制平台或推出糟糕的更改），OpenAI公司将验证他们的系统可以自动恢复并在影响客户之前检测问题。

3.应急控制平台访问

“紧急访问”（break-glass）机制将确保工程师即使在高负载下也能访问Kubernetes API服务器。

4.解耦控制与数据平台

为了减少依赖，OpenAI公司将Kubernetes数据平台（处理工作负载）与控制平台（负责编排）解耦，确保关键服务即使在控制平台中断时也能继续运行。

5.更快的恢复机制

新的缓存和速率限制策略将改进集群启动时间，确保在故障期间更快地恢复。

示例代码：分阶段推出示例

下面是一个使用Helm和Prometheus实现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

用于监控API服务器负载的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服务器请求的响应时间，确保及早发现负载峰值。

故障注入示例

使用混沌网格，OpenAI可以模拟网络中断。

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服务器Pod来验证系统的恢复能力。

这次事件的重要意义

这一事件凸显了设计弹性系统和采用严格测试方法的重要性，无论是在大规模管理分布式系统，还是在工作负载实施Kubernetes。以下是值得借鉴的几个要点：

定期模拟故障：使用混沌工程工具（如 Chaos Mesh）在真实环境下测试系统的鲁棒性。
多层级监视：确保可观察性堆栈同时跟踪服务级别指标和集群健康指标。
解耦关键依赖关系：减少对单点故障的依赖，例如基于DNS的服务发现。

结论

虽然并没有任何系统能够免受故障影响，但像这样的事件再次提醒我们，透明度、快速补救和持续学习至关重要。OpenAI公司主动分享这一事后分析的方法，为其他组织提供了改善其运营实践和可靠性的蓝图。

通过优先考虑稳健的分阶段部署、故障注入测试和弹性系统设计，OpenAI公司为如何处理和从大规模中断中学习树立了一个典范。

对于管理分布式系统的团队来说，这个事件是一个很好的案例借鉴，可以用来研究如何进行风险管理和最大限度地减少核心业务流程的停机时间。

希望我们以此为契机，共同构建更好、更有弹性的系统。

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