1 篇博文 含有标签「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. 质疑你的保障系统——它们可能隐藏着风险

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

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