摘要
2026年7月25日傍晚，OpenAI 旗下 ChatGPT、Codex 及 API 出现全球性大规模错误率升高，持续约 1 小时 51 分，31 个核心组件同时瘫痪，据新浪科技深挖事件期间累计触发约 127 万条告警，免费/Plus 用户与 API 开发者均无法正常对话或调用。官方将根因指向一次云数据库例行维护操作。
时间线
2026-07-25 17:17 (UTC+8)状态页显示错误率升高，影响北美、欧洲、亚太，ChatGPT/Codex/API 全线告警
2026-07-25 17:35 (UTC+8)用户大量反馈登录报错、对话中断、历史记录临时消失
2026-07-25 19:08 (UTC+8)首批受影响服务恢复（官方状态页记录 07:08 PM 对应时段）
2026-07-25 19:57 (UTC+8)全部受影响服务恢复，事件关闭
2026-07-26技术媒体发布复盘，指出为当月第二次大规模中断（7/15 亦有一次）
根因
云数据库例行维护中下线了部分备用节点，剩余在线节点瞬间涌入超额流量；客户端自动重试机制形成"负载—重试—更高负载"的正反馈循环，最终击穿认证模块，导致登录与对话服务整体不可用。OpenAI 官方在状态页确认事件源于云数据库维护操作。
放大因素
- 客户端自动重试机制未做退避与熔断，将瞬时错误放大为持续风暴；重试正反馈形成"错误率升高→客户端重试→请求翻倍→错误率更高"的闭环，最终击穿认证模块（新浪科技复盘）
- 当日正值使用高峰，剩余节点容量裕度不足
- 认证模块成为单点瓶颈，缓存层与登录模块协同节点在极端流量下过载
- 1.27M 级告警洪峰淹没监控，故障定位与止血节奏被拖慢
缓解措施
- OpenAI 快速扩容并分流流量，数十分钟内逐步恢复
- 事后需补齐弹性限流、降级机制与分布式容错设计
经验教训
- 对依赖项的例行维护必须纳入变更管控与容量预演，避免"标准操作"演变为全局故障
- 客户端重试应默认带指数退避与熔断，防止重试风暴
- 关键路径（认证）需独立限流与冗余，避免单点瓶颈
- 参考来源：OpenAI 状态页 https://status.openai.com/incidents/01KYCGY017EG43XZS6GFVXA8VH ；新浪科技 https://k.sina.com.cn/article_7879848900_1d5acf3c40680395ow.html
检查清单
- 依赖项维护是否评估过容量与 failover？
- 客户端 SDK 是否内置退避/熔断？
- 认证链路是否独立限流与多可用区部署？
- 是否做过"备用节点下线"的故障注入演练？