一亿美元的遥测错误：OpenAI 的故障教会我们系统设计的知识

在 2024 年 12 月 11 日，OpenAI 发生了一次灾难性的故障，使 ChatGPT、他们的 API 和 Sora 中断了超过四个小时。虽然故障发生在每家公司身上，但这次故障特别引人注目，因为它揭示了现代系统设计的一个关键教训：有时我们添加的工具以防止故障，反而成为故障的根源。

十亿美元的讽刺

有趣的是：这次故障并不是由于黑客攻击、部署失败，甚至不是他们的 AI 模型中的错误引起的。相反，它是由于一个旨在提高可靠性的工具引起的。OpenAI 正在添加更好的监控以防止故障时，意外地造成了他们有史以来最大的故障之一。

这就像雇佣一个保安，结果他把所有人都锁在了楼外。

故障滚出的雪球

事件的经过如下：

1. OpenAI 部署了一个新的遥测服务，以更好地监控他们的系统
2. 该服务用 API 请求淹没了他们的 Kubernetes 控制面板
3. 当控制面板失败时，DNS 解析也中断了
4. 没有 DNS，服务无法相互找到
5. 工程师无法修复问题，因为他们需要控制面板来移除有问题的服务

但最有趣的部分不是故障本身，而是多个保障系统同时失败：

1. 测试没有捕捉到问题，因为它只在规模上出现
2. DNS 缓存掩盖了问题，足够长的时间让它传播到各处
3. 用来修复问题的系统恰恰是那些崩溃的系统

三个关键教训

1. 规模改变一切

遥测服务在测试中工作得很好。问题只在部署到数千个节点的集群时出现。这突显了现代系统设计中的一个基本挑战：一些问题只在规模上出现。

2. 保障系统可能成为风险因素

OpenAI 的 DNS 缓存，旨在提高可靠性，实际上通过掩盖问题使情况变得更糟，直到为时已晚。他们的 Kubernetes 控制面板，旨在管理集群健康，成为了单点故障。

3. 恢复计划需要恢复计划

最令人震惊的部分？工程师无法修复问题，因为他们需要正常工作的系统来修复损坏的系统。这就像需要一把梯子才能够到你需要的梯子。

系统设计的未来

OpenAI 的响应计划揭示了系统设计的未来走向：

1. 解耦关键系统：他们将 Kubernetes 数据面板与控制面板分开，减少相互依赖
2. 改进测试：他们正在添加故障注入测试，以模拟大规模故障
3. 应急程序：他们正在建立即使在其他一切失败时也能工作的紧急访问系统

这对你的公司意味着什么

即使你不是在 OpenAI 的规模下运营，这些教训依然适用：

1. 在规模上测试，而不仅仅是测试功能
2. 提前建立紧急访问系统
3. 质疑你的保障系统——它们可能隐藏着风险

可靠系统的未来并不是防止所有故障，而是确保我们能够快速而优雅地从故障中恢复。

记住：最危险的问题不是我们能预见到的，而是那些从我们构建的保障系统中突然冒出来的。