一、项目背景

我们的 AI 网关后面挂了十几个模型实例，一开始没做隔离，主模型一挂，所有走它的业务全崩，没有降级也没有回退，一次故障群里炸锅，业务方追着问为什么问答全挂了。我们这才意识到网关层不做可用性治理，一个模型就能拖垮全局。

那次主模型挂全崩，业务方在群里发截图问为什么问答全挂，我们才痛下决心做网关层可用性治理，不然总觉得事不关己。一个模型实例的故障能拖垮全业务，这件事之前我们真没概念，直到被群里的截图打脸才重视。

实例级隔离上线后，我们还做了故障演练常态化，每周随机摘一个实例看业务是否无感，团队从怕故障变成盼演练。因为每次都能验证治理有效，信心来自验证，不是来自口号。

二、落地场景

我们在网关做了实例级故障隔离加降级熔断。每个模型实例独立探测健康，挂了就把它从路由里摘掉，流量切到备用实例。同时配了降级策略，实在没可用实例时返回兜底话术而不是整个服务不可用。备用模型回退也接在编排层。

实例级隔离我们和编排层联动，摘实例的同时把流量切备用，业务侧几乎看不到抖动，这才是真隔离，不是摘了就报错给上游。主模型失败自动切副模型，业务无感，兜底话术也备着，服务永远不返回 503。

熔断规则我们接了告警群，每次摘实例都通知对应模型负责人，谁挂了一目了然，之前故障群里只有业务方在问，现在责任人自己先看到。响应快了一截，故障不再靠用户举报。

这套可用性治理上线后，我们敢接更高等级的业务了，之前怕一个模型挂拖垮全局不敢接，现在实例级隔离加回退保底，业务方也敢把核心问答放上来。可用性从不敢承诺变成能写进 SLA，口碑慢慢起来了，单子也多了。我们还把故障演练常态化，每周随机摘实例验证业务无感，团队从怕故障变成盼演练。可用性写进 SLA 后，商务谈单也硬气了，这不是成本中心而是竞争力，治理才值。

三、关键技术挑战与解决思路

第一个难点是隔离粒度。我们一开始按模型摘，结果同模型不同实例一个挂全摘，误伤严重。改成实例级，挂哪个摘哪个，其他实例照常。第二个坎是熔断阈值，太敏感一有抖动就熔断，正常请求被误伤；太迟钝故障已经扩散才熔断。

熔断阈值我们用滑动窗口平滑，避免单次抖动误杀，也避免持续劣化被平均掩盖，调了几轮才找到手感，太敏感受误伤太钝扩散。第三个坎是回退，副模型能力未必等同主模型，我们给回退标注降级标记，上游知道这是兜底，不计入质量考核。

回退标注降级标记后，上游监控能区分正菜和兜底，质量报表不再被兜底数据污染，我们才敢说可用性达标。否则一直分不清是真稳还是凑合，报表才可信，考核也公平。

四、效果数据

做了实例级隔离后，单次模型故障的扩散面从全业务降到单个实例的流量占比，约 5% 以内。回退成功率在故障演练里到九成以上，业务基本无感。熔断恢复时间从人工介入的几十分钟压到自动几十秒，因为健康探针探活后自动加回路由。

回退演练我们每月做一次，故意摘主实例看业务是否无感，演练里回退成功率稳定在九成以上才放心，单实例故障扩散面压到百分之五内。一个季度重大可用性问题从月均 2 起降到 0，业务方终于不找我们了。

健康探针我们加了多级探活，轻量探活高频、深度探活低频，避免误判，之前只探端口通不通，模型卡死但端口活着的情况漏过。吃过亏才加深度，误杀少了，恢复也快了。

五、可复用经验总结

网关层必须做实例级隔离，按模型摘会误伤，挂哪个摘哪个才对。熔断阈值别只盯一个指标，错误率加延迟双判加滑动窗口，太敏感受误伤太钝会扩散。回退要标降级标记，副模型能力不同等，上游别拿兜底当正菜考核。

可用性治理别等出了事再补，实例级隔离加熔断加回退是标配，健康探针自动恢复比人工救火靠谱太多，演练要常态化。一个模型挂全崩的事故，经历过一次就不想来一回，这套治理花小钱防大灾。

可用性治理我们后来写进上线规范，新模型接入默认带隔离熔断回退，不补就不让上，从救火变预防。这套治理花小钱防大灾，值，每次演练都省下真金白银，业务也敢上核心。

案例片段（已脱敏）： 某政务 AI 网关，挂 12 个模型实例。我们的故障隔离与熔断规则片段：隔离粒度: instance 级, 挂一摘一, 不影响同模型其他实例 熔断: error_rate>0.5 或 p99>3s 持续 30s(滑动窗口) -> 摘实例 回退: 主实例摘 -> 编排层切备用实例, 标注 degrade=true 兜底: 无可用实例 -> 返回兜底话术, 服务不 503 恢复: 探针连续 3 次探活 -> 加回路由演练中单实例故障扩散面<5%，回退成功率 92%，恢复从人工 30min 降到自动 40s。