摘要

  • ChatGPT 图片生成事件从 7 月 21 日 10:36:02 UTC 开始，到 22 日 02:50 UTC 标记解决，约为 16 小时 14 分钟。
  • 状态时间线在缓解和重新调查之间反复，说明改善没有立即稳定。
  • 独立的 API 图片生成高错误事件于 19:33:27 UTC 开始，20:26 缓解，22:19 解决。
  • 两个事件在时间上重叠，但独立记录和重叠本身不能证明共同技术根因。
  • OpenAI 没有公布受影响请求数、地域分布、数据丢失、根因或服务抵扣资格。

状态页最容易被误用的词不是“中断”，而是“缓解”。它通常表示供应商采取了措施、影响正在下降，却不保证所有调用路径恢复、积压已经清空，也不保证问题不会再出现。OpenAI 这次 ChatGPT 图片事件恰好展示了这种差别。

一次故障里出现多次恢复判断

长事件从 10:36:02 UTC 延续到次日 02:50 UTC。期间，OpenAI 曾宣布缓解，随后又回到调查。状态页只反映供应商对组件的观察，不能代表每个用户在每一刻的体验；不过，多次状态逆转足以说明恢复过程并非线性。

对客户而言，风险发生在是否释放积压队列的决定上。如果看到一次“缓解”就重新提交所有任务，故障复发会制造更多失败、重复请求和人工清理。更稳健的做法是少量、限速地发送合成请求，并要求一段连续稳定时间。

最终“已解决”也只说明 OpenAI 认为相关组件恢复。状态记录没有承诺所有早先失败的图片都会自动重放，用户可能仍需重新提交或核对缺失资产。

API 有自己的起点和终点

第二个事件针对 API 图片生成错误，于 19:33:27 UTC 开始，20:26 标为缓解，22:19 结束。它在长事件内部重叠了约两个多小时，却有不同的开始、更新和结束时间。

共同依赖确实可能让界面和 API 同时受影响，但繁忙云服务也可能同时发生无关问题。OpenAI 没有发布原因说明，因此不能把时间相关性升级成同一后端根因。

可用性报告应保留两只时钟。只用 ChatGPT 的团队经历长窗口；只用 API 的系统主要面对后面的错误区间；同时使用两者的组织可能观察到两种不同表现。

缺失指标限制损失结论

两张状态页都没有提供错误请求数量、用户数、地区、账户层级或补偿规则，也没有报告数据丢失。我们能确认服务可用性受损，却不能从公开记录计算全球经济损失。

实际影响机制仍很清楚。编辑、广告和电商流程中，图片可能是发布硬依赖；请求失败会触发重试、重复、审批延误和夜间值守。另一部分拥有缓存素材或替代媒介的用户可能继续工作。没有遥测就不能把两者合并成统一损失。

客户系统需要分别记录请求是否被接受、是否仍在执行、资产是否收到、是否通过人工审核，并使用幂等键防止恢复后生成多个不同结果。供应商状态只是一个信号，不能代替本地结果验证。

两个事件现在都已关闭。可靠结论无需猜测根因：ChatGPT 图片生成在多次缓解后才稳定，API 另有一个重叠但独立的错误窗口。把“缓解”当成“完成”的工作流，会在这类复发里付出额外成本。

来源