OpenAI 服务状态页怎么看？宕机时的正确姿势

调用报错、网页打不开、生成到一半断掉，很多人的第一反应是「是不是我这边配置改坏了」，接着开始改代码、换参数、反复重试——折腾半小时，最后发现平台自己挂了。AI 服务的事故期里，这个方向性的错误最常见也最浪费：所有排查动作都建立在「问题在我这边」的假设上，而真相是上游宕机。排障的正确顺序里，看状态页永远是第一步。这篇把状态页的读法讲全：组件颜色各自代表什么、历史事故记录怎么查、宕机期间该干什么不该干什么，以及恢复之后怎么收尾。

排查第一步：先看状态页，再动配置

排障顺序本身就是一个过滤器：先花三十秒确认「是不是平台的问题」，把服务端故障从排查清单里划掉，剩下的才是你自己的事。状态页的入口很直接：浏览器访问 status.openai.com，或者从帮助中心进入，页面顶端就是当前各服务的实时状态。什么时候必须看？三个信号：报错突然集中爆发、报错类型与你的改动毫无关系（比如你只改了提示词，上传接口却超时）、同一份代码昨天正常今天异常。这三个信号都指向「先看上游」。反过来说，如果状态页全绿而错误持续，问题大概率在调用侧，再去查参数与代码，此时可以对照API 错误结构一篇按错误类型逐项排查。

组件怎么读：绿黄红与影响范围

状态页把服务拆成若干组件行，每行一个颜色圆点。绿色代表正常；黄色代表性能降级——服务还在响应，但变慢、错误率上升，你的调用时好时坏多半对应这种状态；红色代表宕机——对应组件基本不可用。读组件时要对号入座：你在用哪个产品就看哪一行，API 的状态与网页版的状态可以不同步，网页端正常不代表 API 正常，反之亦然。页面上还会滚动显示进行中的事故公告：影响哪个组件、什么时间开始、当前进展如何——公告里的一句「已定位」和「正在调查」，对应的等待预期完全不同，前者可以按小时估，后者连恢复时间都未知。

历史事故与订阅：把被动刷新变主动通知

状态页下半部分是事故历史，这块的价值常被低估。查历史有两个用途：一是判断今天的异常是不是已知问题的延续——此刻还没挂上公告栏、但一小时前刚有过一次降级的组件，值得多留个心眼；二是复盘时对时间线——把你的报错日志时间戳与状态页事故起止时间对照，损失面（哪些任务失败、哪些会话中断）一目了然，该重跑什么心里有数。订阅更新是另一个省心的功能：Subscribe to Updates 之后，事故的发生与恢复会推送给你，事故期间不用反复手动刷新，等通知即可。各家 AI 服务其实都有类似的公告渠道，DeepSeek 开放平台、豆包背后的火山方舟也提供公告与状态入口，习惯养成一次，以后排查任何家的服务都是同一套动作。

等待策略：为什么狂重试反而更糟

确认上游异常之后，正确姿势是停下来，而不是换个姿势继续撞。狂重试的坏处有两层：在限流与降级场景下，密集重试只会把你推进更严的限流窗口，恢复之后还得排队等额度，跟「越挤越堵」一个道理，重试节奏怎么设才不添乱，重试越多越好？一篇拆过这个误区；在宕机场景下，重试只是白白消耗你的调用次数与客户端资源，事故公告没说恢复，重试就是空转。标准的等待姿势按顺序做：确认状态页标红或标黄的组件与你的症状对得上；停掉定时任务与自动重试脚本，别让它们在事故期空跑刷日志；订阅更新通知；等组件恢复绿色后再用一个轻量请求验证——通了才把积压的任务放出来，且放任务时控制速率，给刚恢复的服务留缓冲。带自动重试的系统尤其注意：指数退避要配上限，事故期自动重试等于用你的配额给上游添堵。

恢复之后：对时间线、补损失、留记录

服务恢复不等于事件结束，收尾三件事值得做。第一，对时间线：把事故起止时间与你的失败记录对照，圈出事故窗口内失败的请求，逐个标记重跑——批处理任务、夜间任务尤其容易在事故里整批搁浅，回收动作见Batch API一篇的失败条目处理。第二，查连带影响：事故期的错误可能触发了你的告警、重试风暴或队列积压，逐项确认清干净再恢复正常节奏。第三，留记录：把这次的现象、报错样式、持续时间写进团队的运维记录，下次再遇到同样报错，三十秒就能判断是不是同一类事故。如果事故期间产生了异常计费或用量激增，对账方法见账单异常排查一篇。

宕机应对速查

• 排障第一步看状态页，先划掉「平台挂了」这个选项
• 绿正常、黄降级、红宕机；API 与网页版状态分开看
• 公告「已定位」可按小时估，「调查中」没有恢复预期
• 事故期停重试、停定时任务，订阅更新等通知
• 恢复后轻量请求验证，再小步放出积压任务
• 对时间线圈失败任务重跑，记录进运维日志

关于服务状态页的常见疑问

• 状态页全绿但我的请求一直失败，算谁的问题？：先假设是你这边的问题。状态页只反映平台确认的、影响面足够大的事故，区域性或小范围的异常未必上榜；此时按常规排障走：核对错误码与报错结构、换网络环境交叉验证、最小化请求复现。持续失败且分布在不同网络环境里，再考虑反馈给官方支持。
• 黄色降级状态期间，任务该继续跑还是停？：看任务的失败成本。重要任务停一等，降级期错误率上升，跑得越多废得越多；不重要的任务可以继续，但要把重试间隔拉长、次数收紧。Interactive 的实时对话在黄色期间体感最明显，等待回复变慢属于正常现象，不必反复刷新。
• 历史事故记录能保留多久？：状态页的 incident history 保留时间有限，更早的记录不一定还能翻到。有长期复盘需求的团队，建议在每次事故收尾时把状态页截图与公告内容存进自己的运维记录，别依赖平台替你存历史。

状态页管的是「平台整体挂没挂」；单条请求层面更细的报错分流，网页端的常见报错清单见ChatGPT 页面报错集一篇，两篇配合着用，故障定界就完整了。