OpenAI宕机3小时，这家公司用45分钟造了条逃生通道

去年12月，OpenAI的API挂了4小时。一家做客服自动化的创业公司当天损失了23%的工单处理量，客户投诉炸了锅。他们的CTO后来复盘：「我们花了9个月搭AI流水线，却从没想过模型会突然消失。」

这不是技术债，是认知债。大多数人把AI当水电，默认它永远在线。但模型服务比CDN脆弱得多——供应商宕机、配额耗尽、版本回滚，甚至一条prompt触发安全拦截，都能让你的agent瞬间变砖。

更麻烦的是，AI故障不像数据库挂了那样干脆。它可能返回幻觉内容、超时30秒、或者给出置信度极低的结果。你的代码还在跑，但产出的东西已经不能用了。

第一步：画出你的AI血管图

找个白板，把所有人机交互里调用模型的地方全列出来。不要漏掉那些「隐形」调用——PR自动review、文档生成agent、内部客服机器人、甚至Slack里的摘要bot。

我见过一个团队以为自己只有2个模型入口，实际数出来17个。三个是实习生写的实验脚本，已经跑了大半年没人管。

列完之后标依赖关系。哪些调用是串行的？哪些是并发的？一个客服triage失败，会不会阻塞后续的工单分配？这张图的价值在于，让你看清故障的级联路径。

关键动作：用统一ID追踪每次调用，从入口到最终输出。没有trace ID，事后复盘就是猜谜。

第二步：给流程贴交通灯

把每个模型调用按业务影响分级：

红色：中断即停损。支付风控、实时客服、生产环境代码生成。这类流程如果模型不可用，必须立刻有替代方案，哪怕牺牲部分智能化。

黄色：延迟可接受。内部报告生成、非紧急内容审核、批量数据处理。可以排队等恢复，或者降级到规则引擎。

绿色：纯实验性质。A/B测试、内部demo、可选功能。这类直接失败即可，不需要fallback。

分级的难点在于诚实。很多产品经理会把自家功能全标成红色，直到你问他：「如果这功能手动做，需要多少人？」真正的红色流程，手动替代成本是分钟级损失或合规风险。

第三步：造一个机械心脏

Fallback不是「换个API key」那么简单。你需要确定性降级——当模型不可用时，系统行为是可预测的，而非随机崩溃。

具体做法：为每个红/黄路径定义主备策略。主模型失败3次/60秒内，自动切换到备用方案。备用可以是另一个供应商、本地小模型、或者纯规则引擎。

设置一个核心指标：provider_failover_count，按工作流维度统计。这个数字飙升，说明你的主依赖已经不稳定，是决策级信号，不是可以忽略的告警噪音。

但自动切换只是半条命。真正的kill switch需要人工熔断能力——当备用也失效，或者你怀疑模型输出被污染时，能一键切到纯人工模式。

检验标准：如果15分钟内无法从故障中恢复，你拥有的不是kill switch，是一份runbook和祈祷。

第四步：每周演一次火灾

选一个非关键工作流，故意触发failover。观察团队反应：监控是否及时告警？值班人员是否知道切流步骤？业务方是否理解降级后的体验变化？

很多团队第一次演练会发现，fallback逻辑写了但配置没上线。或者备用模型的quota早就用完了。这些问题在真实故障中暴露，代价是几小时的业务中断。

演练的频率比完美更重要。每周一次粗糙的演练，胜过季度一次精心编排的表演。目标是让failover成为肌肉记忆，而非紧急时刻翻文档。

AI系统的韧性，最终体现在人的冷静程度上。

45分钟能搭完骨架，但真正的kill switch是持续迭代出来的。每次演练后的复盘、每个边缘 case的修补、每次供应商变更后的重新评估，都在加固这条逃生通道。

你的团队最近一次故意搞崩AI流程是什么时候？如果答案是「从没试过」，那你的kill switch可能只存在于架构文档里——那个没人更新、也没人真信的地方。