摘要

  • OpenAI 在 15:36:02 UTC 开启 01KY7SX5MYJ2BP51X5MXAPYX71 号错误率升高事故。
  • 状态记录列出 12 个 API 组件、两个 ChatGPT 组件和四个 Codex 组件。
  • 16:48:54 UTC，OpenAI 称正与下游基础设施供应商实施缓解措施。
  • 在 17:23:49.505 UTC 固定报道截止时，事故仍为 identified，尚未 resolved。
  • OpenAI 没有披露下游供应商、根因、地区、请求失败率或受影响客户数。

状态组件是供应商组织信息的方式。一个组件可能覆盖许多请求和用户，多个组件也可能依赖同一底层系统。因此，把受影响组件数量当成事故规模会产生两个错误。

第一，18 个组件不是 18 次独立故障。第二，组件数量不能说明有 18 个客户群或多大比例的请求失败。

可以确认的是范围：API、ChatGPT 和 Codex 三类产品都在同一个事故记录里。客户如果在应用中调用 API、用 ChatGPT 进行交互、用 Codex 完成编码，不能仅凭不同产品名称假定它们完全故障独立。

这也不能证明所有产品共用一个物理组件。传播路径仍需技术说明。

下游依赖被披露，但没有被命名

OpenAI 在 16:48:54 表示，正与下游基础设施供应商实施缓解。这句话把一部分控制边界放在 OpenAI 之外。

它没有说明供应商是哪一家，也没有说对方是故障起点还是仅参与修复。不能把事故归给某个云平台、网络、数据中心或其他厂商。

对用户而言，服务和状态沟通仍由 OpenAI 提供；对 OpenAI 而言，缓解需要供应链协作。披露依赖有助于解释控制范围，但不是责任自动转移。

状态页只说错误率升高，没有提供总请求、失败请求、地区和客户数。也没有财务损失、服务抵扣或每名客户持续时间。任何比例或金额都缺少分母。

截止时间不能被后续状态覆盖

事故在 15:36:02 开始，随后从调查进入已识别状态。OpenAI 多次表示正在实施缓解，并在 16:48:54 增加下游供应商信息。

本稿冻结在 17:23:49.505 UTC。截止时事故仍未解决。即使之后出现新进展，也必须标注新时间，不能回写为截止时用户已经知道的结果。

在这个时点，客户仍要决定等待、重试或更换流程。等待会推迟工作，重试会增加人工和请求，切换则需要确认此前操作是否完成。状态记录没有量化这些成本，但不确定性真实存在。

客户自己的请求日志因而比组件数量更适合衡量实际影响：成功率、重试次数、排队时间和未完成工作可以形成自身分母。状态页提供外部事件边界，两类记录需要对时后才能计算组织损失。

后续需要的是最终时间线、触发机制、跨产品传播路径、下游控制边界和防止复发的措施。在这些信息出现前，最准确的结论不是“大规模宕机”，而是三类 OpenAI 产品出现相关错误、缓解依赖未具名下游供应商、实际规模仍未知。

来源