AI 供应商故障手册：告警、降级与复盘怎么串起来

供应商波动不只是技术问题

很多团队把 AI 供应商故障理解成“接口偶尔超时”。真正进了生产环境之后，你会发现它影响的是整条业务链：

• 请求成功率突然下降
• 页面等待时间显著变长
• 单次任务重复重试，成本一起上升
• 客服和运营最先收到用户投诉

所以，供应商故障不该只留给后端临场处理，而应该提前写进值班手册。

先定义什么叫“进入故障态”

最常见的问题是，团队知道系统“有点不稳”，但没有统一的触发标准。

至少要提前约定三类门槛：

• 错误率门槛：例如 5 分钟窗口内失败率超过某个比例
• 时延门槛：例如 P95 延迟持续高于平时两倍
• 功能门槛：例如图像生成、长上下文、结构化输出等关键能力异常

只有门槛清晰，值班同学才知道什么时候该从观察切到行动。

降级路径要写成可执行顺序

故障发生时，最怕的是每个人脑中都有一套“也许可以切这个”的方案。

一条更稳妥的降级链通常包括：

1. 同供应商内切更稳的备选模型
2. 如果仍异常，切到第二供应商
3. 对高成本或长耗时任务临时收紧配额
4. 暂时关闭非核心入口，优先保住主流程

这里的关键不是“绝对最优”，而是让任何值班同学都能按同一顺序执行。

对外通知不能等到完全查明

很多团队通知太晚，是因为总想先把根因查清再同步。

更实际的做法是分两层：

• 内部通知：告诉研发、客服、运营，哪些模型受影响，当前是否已经切换
• 用户通知：告诉用户哪些功能会变慢、哪些任务建议稍后重试

通知的目标不是解释所有细节，而是管理预期，减少无效排查和重复工单。

复盘要回到“为什么没有更早切换”

故障结束后，复盘不要只停留在“上游波动导致失败”。

更有价值的问题是：

• 告警是否足够早
• 切换动作是否靠人工判断太多
• 降级后成本是否超出预期
• 用户是否仍能完成关键任务

如果这些问题不回到配置、监控和产品动作里，下次故障还是会以同样方式重演。

把故障手册写清楚，本质上是在给 AI 能力增加运营韧性，而不是单纯给系统补一层重试。