一亿美元的遥测错误:OpenAI 的故障教会我们系统设计的知识
在 2024 年 12 月 11 日,OpenAI 发生了一次灾难性的故障,使 ChatGPT、他们的 API 和 Sora 中断了超过四个小时。虽然故障发生在每家公司身上,但这次故障特别引人注目,因为它揭示了现代系统设计的一个关键教训:有时我们添加的工具以防止故障,反而成为故障的根源。
十亿美元的讽刺
有趣的是:这次故障并不是由于黑客攻击、部署失败,甚至不是他们的 AI 模型中的错误引起的。相反,它是由于一个旨在提高可靠性的工具引起的。OpenAI 正在添加更好的监控以防止故障时,意外地造成了他们有史以来最大的故障之一。
这就像雇佣一个保安,结果他把所有人都锁在了楼外。
故障滚出的雪球
事件的经过如下:
- OpenAI 部署了一个新的遥测服务,以更好地监控他们的系统
- 该服务用 API 请求淹没了他们的 Kubernetes 控制面板
- 当控制面板失败时,DNS 解析也中断了
- 没有 DNS,服务无法相互找到
- 工程师无法修复问题,因为他们需要控制面板来移除有问题的服务
但最有趣的部分不是故 障本身,而是多个保障系统同时失败:
- 测试没有捕捉到问题,因为它只在规模上出现
- DNS 缓存掩盖了问题,足够长的时间让它传播到各处
- 用来修复问题的系统恰恰是那些崩溃的系统
三个关键教训
1. 规模改变一切
遥测服务在测试中工作得很好。问题只在部署到数千个节点的集群时出现。这突显了现代系统设计中的一个基本挑战:一些问题只在规模上出现。
2. 保障系统可能成为风险因素
OpenAI 的 DNS 缓存,旨在提高可靠性,实际上通过掩盖问题使情况变得更糟,直到为时已晚。他们的 Kubernetes 控制面板,旨在管理集群健康,成为了单点故障。
3. 恢复计划需要恢复计划
最令人震惊的部分?工程师无法修复问题,因为他们需要正常工作的系统来修复损坏的系统。这就像需要一把梯子才能够到你需要的梯子。
系统设计的未来
OpenAI 的响应计划揭示了系统设计的未来走向:
- 解耦关键系统:他们将 Kubernetes 数据面板与控制面板分开,减少相互依赖
- 改进测试:他们正在添加故障注入测试,以模拟大规模故障
- 应急程序:他们正在建立即使在其他一切失败时也能工作的紧急访问系统
这对你的公司意味着什么
即使你不是在 OpenAI 的规模下运营,这些教训依然适用:
- 在规模上测试,而不仅仅是测试功能
- 提前建立紧急访问系统
- 质疑你的保障系统——它们可能隐藏着风险
可靠系统的未来并不是防止所有故障,而是确保我们能够快速而优雅地从故障中恢复。
记住:最危险的问题不是我们能预见到的,而是那些从我们构建的保障系统中突然冒出来的。