4月20日，ChatGPT全球大面积宕机了。
美东时间上午10点多，Down Detector上的故障报告开始激增。英国的报告峰值超过8700份，美国超过1900份。除了ChatGPT主界面，Codex、API平台、Projects功能也一起挂了。部分用户反映正在进行的工作任务因为服务中断被删除了。
到下午1点，OpenAI上线了修复；1点半左右基本恢复正常。整个中断时间大约3小时。
OpenAI怎么回应的
全程，OpenAI状态页的表述是这样的：
“我们继续调查列出服务的问题。”
以及：
“我们已实施缓解措施，正在监控恢复情况。”
没有根本原因说明，没有技术细节，没有复盘报告。
这不是第一次了。ChatGPT历史上几次大规模宕机，OpenAI都没有提供类似AWS或Google Cloud那种详细的事后故障分析——那类报告会说清楚：哪个组件出了问题、为什么影响到这么多用户、下次怎么防。OpenAI每次给的都是最少信息。
这3小时对企业意味着什么
3小时可能听起来不长，但对已经把AI嵌入工作流的团队来说，影响是具体的：
- 正在跑的Codex任务中断，进度丢失
- 接入OpenAI API的产品功能全部失效
- 用ChatGPT处理实时客户请求的团队彻底停工
- 部分用户的工作内容因故障被系统删除
企业在认真对待AI基础设施可靠性这件事之前，这类事件的代价还是会被低估。
为什么AI服务比传统SaaS更容易出问题
几个结构性原因：
流量高度集中：ChatGPT是全球访问量最大的AI产品之一，任何单点故障波及面都极广。
推理链路复杂：大模型推理不像传统API的简单请求-响应，负载均衡和容错机制更难设计，出了问题也更难快速定位。
迭代速度太快：模型更新和功能迭代频繁，每次部署都可能引入新的不稳定因素。AWS和Google Cloud有几十年的可靠性工程积累，AI服务厂商的工程体系还在追赶中。
SLA问题：AI行业还没认真回答
大多数成熟SaaS会提供99.9%的SLA（服务等级协议），对应每年宕机时间不超过8.7小时；更严格的99.99%则把年宕机时间压到52分钟。
OpenAI目前没有公开的企业SLA承诺。Anthropic也没有。
这意味着：大量企业把核心业务流程押在了一个没有明确可靠性承诺的服务上，合同里也没有因为宕机赔偿的条款。这不是一个小问题，特别是当AI已经进入生产环境的核心路径时。
如果你的业务依赖AI，该想清楚的事
多厂商策略：关键业务同时接入两套API，比如OpenAI和Anthropic。一个挂了另一个还能跑。实现成本不高，但要提前做好路由逻辑。
本地模型备份：非实时任务可以用本地部署的开源模型做降级方案，延迟容忍度高的场景先缓存请求、等服务恢复再处理。
合同条款：跟AI厂商签企业合同时，把可靠性要求写进去——即使厂商目前没有标准SLA，也要有明确的故障通知和补偿机制的约定。
代码层面的韧性设计：超时处理、重试逻辑、fallback路径，这些不是可选项，是接入外部AI API的基本工程要求。
这次宕机不是OpenAI第一次，也不会是最后一次。AI基础设施走向成熟的路上，这类事会一直发生。问题只有一个：已经在生产环境用AI的团队，有没有认真设计过应对预案。
参考来源：ChatGPT was down — Live updates on the massive AI outage（Tom's Guide）；ChatGPT was down for many — as OpenAI says it's 'monitoring the recovery'（TechRadar）；OpenAI's ChatGPT Down for Thousands of Users（GV Wire）；ChatGPT Down: Thousands of Users Hit by Major Outage on April 20（TechGenyz）