一、项目背景

某客户的模型服务最初只部署在单可用区，一次机房网络抖动直接让调用方全线报错，业务中断近一小时。我们当时接到的要求是：模型服务不能比传统应用更脆弱。容灾对推理服务不是锦上添花，而是上线门槛。项目视角很明确：推理服务一旦不可达，上游所有智能功能瞬间哑火，它的可用性要求不该低于普通应用。

二、落地场景

场景有三层。一是多可用区部署：同一模型在至少两个可用区各起一组实例，流量按比例分摊。二是健康探测与自动切换：网关对每个区做秒级健康探测，异常区流量自动切走。三是流量灰度回切：故障区恢复后不直接全量回切，先小比例灰度验证再放大。四是故障演练：定期人为切断一区，验证切换链路真的通的，而不是纸面方案。

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

难点一是探测的准确性，过于敏感会误切、过于迟钝会漏切，我们用连续多次失败加延迟阈值双条件判定，过滤掉瞬时抖动。难点二是状态一致性，推理服务本身无状态，但缓存和路由表要同步，切换后不能出现"切过去了但路由还是旧的"。难点三是回切验证，恢复后先做影子流量比对两区输出一致性，再放量，宁可慢一点也要稳。

案例片段（已脱敏）： 一次演练中我们主动隔离B区，网关在约八秒内把流量切到A区，错误率曲线瞬间回落。B区恢复后先放百分之五影子流量比对，输出一致率达约九成九后，两小时平滑回切到五五开，全程业务侧无感知，演练报告成了后续上线的信心来源。

四、效果数据

上线后服务可用性从约两个九提升到约三个九五；单次故障自动切换耗时从人工介入的分钟级降到约十秒级；回切验证覆盖率达百分之百；因单区故障导致的业务中断时长从年均约数小时降到零。演练频次保持每月一次，确保链路不是上线即过期。

五、可复用经验总结

容灾要自动切，人介入的容灾在大半夜永远慢半拍。回切要验证，恢复不等于健康，影子流量比对是安全带。探测要双条件，灵敏度和稳定性只能靠阈值工程平衡。把演练当日常，容灾链路不演不灵，纸面方案在真实故障面前往往不堪一击。

结语

容灾这件事，最大的坑是"以为有了就安全"。我们吃过演练不足的亏，后来把"每月一切"写进运维铁律，切换链路才真正可信。对推理服务来说，可用性是它的第一产品属性。

附：规模化落地的工程取舍

我们把多可用区容灾从单模型推广到全部关键模型时，最关键的取舍是探测灵敏度。太敏感会误切导致抖动，太迟钝又漏切拖垮业务。最终我们用连续多次失败加延迟阈值双条件判定，并针对不同模型的延迟基线分别调参，避免一刀切。回切我们坚持影子流量比对，即使故障区恢复也不立刻放量，先放百分之五验证输出一致再逐步回切，宁可慢一点也要稳。

附：给同行的一些提醒

第一，容灾要自动切，人介入的容灾在大半夜永远慢半拍，推理服务不可达上游全哑火。第二，回切要验证，恢复不等于健康，影子流量比对是安全带，别省这一步。第三，探测要双条件，灵敏度和稳定性只能靠阈值工程平衡，没有银弹。第四，把演练当日常，每月切一次，纸面方案在真实故障面前不堪一击。第五，可用性要按模型分级，不是所有模型都值得三个九五，把资源投在真正高频关键的模型上。

附：我们踩过的几个坑

第一坑是误切，早期探测太敏感，一次网络瞬时抖动就切走流量，造成不必要的抖动，加双条件判定才稳。第二坑是路由滞后，切换后路由表没同步，流量切过去了但还指向旧实例，我们补了状态同步才彻底解决。第三坑是回切莽撞，故障区刚恢复就全量回切，结果该区其实还没完全健康，又抖一次，后来强制影子流量比对才安心。这几坑让我们明白，容灾链路每一环都可能成为新的故障点，只有反复演练才能把纸面方案变成真功夫。

附：回到工程本质

容灾这件事最深的体会是：拥有不等于安全，演练过才叫拥有。我们见过太多纸面多活方案，真出故障时发现切换脚本没更新、路由没同步、回切没验证，反而添乱。把每月一切写进运维铁律，切换链路才真正可信，可用性指标也才敢对外承诺。

另一点体会是，资源要按模型分级投。不是所有模型都值得三个九五的可用性，把保活、双活、演练的成本集中在真正高频关键的模型上，既不浪费也不冒险。一刀切的高可用，最后要么超预算要么流于形式。

附：一点补充

补充一点，容灾的成本要算总账。双活实例、健康探测、影子流量比对，每一层都占资源，但如果换成一次业务中断的赔偿和口碑损失，这笔账永远划算。我们后来把中断时长和客户赔偿做了折算，直接证明容灾投入的回报周期远短于多数人直觉，这也是说服业务方持续投入的关键。