把 API 宕机当「事故」，而不是「新闻」：一份 72 小时应急清单

2026 年 7 月中旬，主入口 AI 推理路由停摆了 72 小时。不是 PR 危机，没有外部媒体报导，内部读者只看到页面返回 502。但从那天起，我们把「API 宕机」从玄学变成了 checklist：动作、责任人、时间戳，缺一不可。

第一步：确认是谁在哭

宕机发生后 5 分钟内，第一份工作不是写公关稿，而是三件事：

- 确认受影响范围：哪条路由（api 节点、推理网关、缓存层、CDN）报错？日志关键字是什么？

- 检查降级链路是否触发：有没有自动切到 fallback 模型或本地缓存？

- 通知内外部利益相关者：用站内消息通知技术团队、编辑团队、以及当前正在排队请求的业务方。

这一步只消耗 5 分钟，但能避免「整条产线莫名降级」的持续性浪费。

第二步：拉起战情室（后查，非猜测）

宕机 15 分钟还没有恢复迹象时，指定唯一的决策人。这个决策人不是「技术负责人」，而是「知道该怎么报价的人」——通常是不负责本次故障的 senior 工程师，因为 ta 不会陷入「自救幻觉」，反而能看清全局。

决策人只负责三件事：

- 是否延长降级方案（比如切到备用路由）？

- 是否启动应急内容发布（如覆盖页、状态页）？

- 是否通知客户预计恢复时间？

其他所有人关闭工单、只回复「等待指令」。这不是军事化，而是防止反复切换导致问题复杂化。

第三步：给读者一个遮羞布

如果你的产品面向全球用户，502 页面必须国际化。

我要求团队维护至少三个版本的临时页面：

- zh-CN: 「我们正在恢复服务，预计 XX 分钟。」

- zh-TW: 「我們正在恢復服務，預計 XX 分鐘。」

- en: "Service temporarily unavailable. Estimated recovery in XX minutes."

并且，每 30 分钟更新一次时间。这不是心理安慰，而是向读者传递「我们仍在监控」的信号。

第四步：事后复盘——不追责，只追流程

宕机结束后 24 小时内，召开一次「复盘会」。会议只讨论三个问题：

1. 时间线是否完整？（从宕机开始、发现、降级、恢复、通知，每个节点是否有记录？）

2. 哪一步慢了？（比如：调用路由、人工决策、客户通知，哪个环节超过正常阈值？）

3. 哪个预案没生效？（比如：自动切换失败、监控未覆盖、文档未更新）

不点名、不扣绩效。如果复盘后不更新文档和检查点，等于什么都没学。

第五步：把 checklist 变成「肌肉记忆」

最后，把这份 72 小时清单拆解成 72 小时以内的**单项动作**，存放在每个团队的共享文档中。每次演练后更新。半年后回顾，你会发现：团队对宕机的反应从「慌了」变成「按清单走」。

---

*不是要你祈祷 API 永不宕机，而是希望它宕机时，你有一张能救场的地图。*