ChatGPT背后的公司OpenAI刚刚经历了自上线以来最动荡的时期之一。仅2026年7月一个月，就接连发生多次宕机，并在一次大范围的全球性中断中达到顶峰，随后又出现了一起持续近一整天的事故。本文依据OpenAI官方状态页面公布的日期和时间，准确记录了所发生的一切，并解释这在实践中对任何基于AI构建业务的公司意味着什么。

撰写时的实时状态

在准备本报告时，即2026年7月25日星期六利雅得时间12:20，OpenAI官方状态页面显示有一起正在调查中的活跃事故，标题为"Elevated error rates"（错误率升高）。该事故于利雅得时间12:17（09:17 UTC）正式开始，同时影响了三项服务：ChatGPT、OpenAI API以及编程工具Codex。该公司将影响评定为"轻微"，并将平台整体状态描述为"Partial System Degradation"（部分系统降级）。换句话说，这并不是一次全面的全球性瘫痪，而是部分用户遇到间歇性变慢和请求失败。

动荡两周的时间线

今天的事故并非孤立事件，而是贯穿整个7月的一长串事故中的一环：

  • 7月9日：多个模型同时出现"Please try a different model"（请尝试其他模型）错误。
  • 7月11日至15日：据报道，连续五天发生五起事故，最后以一次明显的宕机收尾，之后ChatGPT恢复正常。
  • 7月19日：一次重大的全球性宕机，记录了超过250条报告，影响了乌克兰、美国、欧洲、印度和日本的用户，主要集中在iOS上，出现502和503错误。
  • 7月21日：一次持续约23分钟的短暂宕机。
  • 7月23日至24日：最严重的一次事故。它于23日利雅得时间18:36开始，在经历了起伏不定的稳定性之后，直到24日22:33才被宣布完全恢复。
  • 7月25日：当前的活跃事故，影响轻微，正在调查中。

根本原因是什么？

在OpenAI关于7月23日至24日事故的官方更新中，一个关键细节是：他们明确表示正在"与下游基础设施提供商"共同进行修复。这意味着问题的根源很可能出在OpenAI所依赖的托管和云网络层，而不是AI模型本身。这也解释了为什么本周大多数事故表现为错误率升高和502/503错误，而不是彻底停摆：服务仍在运行，但有一部分请求失败或延迟。

为什么即使您从不打开ChatGPT，这件事也很重要

因为这次宕机影响的是OpenAI API，而不仅仅是ChatGPT网站。成千上万的应用、商店和客户服务系统在后台调用OpenAI模型，最终用户对此毫无察觉。当API错误激增时，所有这些系统会在同一时刻出现故障。任何只依赖单一提供商、没有备用方案的人，都会把该提供商的宕机变成自己的宕机。

教训：为故障而设计

大型提供商也会宕机，这是常态，而非例外。脆弱系统与弹性系统的区别，在于它在那一刻的表现：

  • 多提供商：为您的系统配置一个备用模型提供商，当主提供商出现故障时自动切换过去。
  • 智能重试：请求失败时，采用指数退避方式重试，而不是用更多流量冲击一个本已不堪重负的服务。
  • 请求队列：将非紧急请求保存下来，待服务恢复后再执行，而不是让它们丢失。
  • 监控与告警：关注错误率和延迟，一旦超出正常范围立即收到告警，而不是等到客户投诉时才知道。

Origami的定位

作为一家科技公司，我们不只是把您的业务接入某个AI模型，而是以"提供商总有一天会出故障"为前提来设计集成方案：在提供商之间设置自动故障切换层、规范的重试机制，以及能够在客户之前发现宕机的监控面板。正因如此，当别人停摆时，您的系统依然屹立不倒。

来源