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