OpenAI状态页的12+2+4是组件范围，不是故障规模

摘要

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

第一，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产品出现相关错误、缓解依赖未具名下游供应商、实际规模仍未知。