模型服务的灾备与降级：预案的工程学

弹性伸缩与灰度发布的文章讲过怎么让服务扛住流量、平稳换代，这篇讲坏事真正发生时的工程学：灾备与降级。预案的本质是把灾难天的决策提前到平时做完，它考验的不是临场智力而是准备纪律。模型服务的故障域比传统网页服务更宽，预案也要相应加宽——除了机房与依赖，模型本身就是新的故障源。

故障域分析：先知道会怎么坏

区域与机房级故障

第一类故障域是基础设施级：机房断电、网络中断、区域级灾难。单机或单柜故障靠集群冗余消化，此前的故障工程文章讲过；机房级故障则要求服务具备跨机房部署的形态。云上部署同样成立：单可用区故障是高频事件，多可用区部署是推理服务的基本盘。区域级故障概率低但影响全灭，是否为它支付跨区域的成本，取决于业务的量级与中断容忍度，这正是后面恢复目标讨论的输入。

依赖服务与模型版本事故

第二类故障域是依赖链：模型服务依赖的上游——鉴权、计费、特征存储、向量数据库、第三方模型接口——任何一个故障都会传导到终端体验。依赖故障的特点是我的代码没变但服务死了，预案重点是依赖的降级开关与替代路径。第三方模型接口值得单独点名：把外部模型当作依赖的服务，等于把自己的可用性与对方的容量管理绑在一起——对方限流、故障或调整接口，你的服务立即感知。预案至少要有三层：多家供应商的冗余路由、本地小模型的应急兜底、以及把「外部依赖不可用」与「自家故障」在监控口径上区分开，否则事故定位会浪费在最不该浪费的地方。第三类故障域是模型自身：新版本上线后质量劣化、幻觉率飙升、输出格式崩溃，或者模型文件与配置损坏。版本事故的特殊性在于它不是资源故障而是「智能故障」：延迟、错误率这些传统指标可能全部正常而业务质量已经塌了——所以评测文章里反复强调的线上质量监控，本身就是灾备体系的一部分。故障域分析的产出是一张清单：每类故障的影响范围、检测手段、首要处置动作。没有这张清单的预案是散文。

灾备的三个层次

同机房与跨机房冗余

第一层是同机房冗余：服务多实例跨机柜部署，存储多副本，机房内任何单点故障自动切换。这一层解决硬件故障，成本增量小，是无条件的底线配置。第二层是跨机房或多可用区：推理服务在两个机房同时承载流量，数据层做实时复制。这层解决机房级故障，成本主要在数据复制的延迟与带宽，对延迟敏感的服务要评估切换对响应时间的影响。推理架构里缓存状态的跨机房迁移特别困难——会话状态与缓存要明确哪些可以放弃重建、哪些必须持久同步，预案里写清楚，切换时才不会临场纠结。数据复制的模式与恢复点目标直接挂钩：同步复制付出延迟换来近零丢失，异步复制流畅但故障窗口内的数据会丢，两条路的混合按数据类型分配——计费类走同步或准同步，会话类接受异步的少量丢失。复制链路本身也要监控：断掉的同步如果不告警，主备就成了假备份。冗余的另一个敌人是共享依赖：两个机房用同一个对象存储、同一家域名解析、同一个配置中心，故障时一起倒下。灾备设计要沿着依赖链往下游找，直到找到真正独立的根；共享依赖要在预案里显式标注，能替换的替换，不能替换的接受这个故障域并写进恢复目标。

跨区域灾备

第三层是跨区域：在地理上独立的区域维持一套可快速拉起的完整环境，平时低配待命或热备，灾难时扩容接管。这一层成本显著，通常只对核心业务配置。模型服务的特殊性在于权重是最大的资产：模型权重与关键配置必须在异地保存副本。训练可以重来——此前讲 checkpoint 的文章说过断点恢复的机制，但线上服务的快速重建依赖的是模型制品、配置、镜像与基础设施描述四位一体的异地副本。灾备层次的选型公式很简单：为业务的中断容忍度买对应层次的冗余，不要为小概率灾难付超出承受力的成本，也不要用「我们不会那么倒霉」替代基本冗余。

降级预案清单

降级是灾备的软件面：灾难以各种形状到来，降级让服务以降低的形态继续活着。模型服务的降级阶梯从上到下：备用模型——主模型故障或过载时切到备用模型，可以是更小的自研模型或不同供应商的模型，质量略降但服务可用，此前的 API 网关文章讲过路由与灰度机制，降级路由是它的灾备应用；简化模式——砍掉长上下文、多模态、工具调用等高耗特性，只保留核心能力，换取吞吐与稳定；静态兜底——模型完全不可用时，高频问题的缓存答案与预置模板顶上，智能归零但业务不断线；排队与限流——流量超载时不硬扛，排队进入加限流保护，此前的 SLA 与压测文章讲过容量水位，降级阈值应该从压测数据里来而不是拍脑袋。降级还是一次用户体验设计：排队要有进度反馈而不是静默转圈，降级到小模型要不要在响应里声明、声明到什么程度，恢复后的补偿与重试怎么给——这些细节提前设计好，故障时的服务形态才是受控的降级，而不是随机的劣化。用户对故障的容忍度远比想象高，对不明所以的失败容忍度远比想象低。降级预案还有一个常被遗忘的部分：恢复。降级降得下去，也要升得回来——流量从备用模型切回主模型、从简化模式恢复完整功能，切换的顺序与验证标准同样要写进预案；事故处置的下半场比上半场更容易出错，因为大家的紧张感已经松懈。每级降级都要预先回答三个问题：什么条件触发、谁有权触发、怎么执行。预案里写不清楚这三个问题的降级，等于没有。

舱壁：别让一个依赖拖沉整条船

依赖故障的预案里有一层工程细节叫隔离舱：给每个依赖设置独立的超时、重试上限与并发额度，任何一个依赖变慢时只烧掉自己那份额度，而不是耗尽整个服务的线程与连接池。没有舱壁的服务，一个慢依赖就能把看起来无关的功能一起拖死——资源是共享的，拥堵是传染的。熔断是舱壁的升级动作：依赖连续失败达到阈值就主动短路一段时间，期间直接走降级路径，给依赖喘息也给自己省资源。这些机制平时看着是过度设计，第一次依赖抖动时就知道值回票价。

恢复目标：用两个数字管理灾难

恢复时间目标是故障发生到服务恢复的最长可接受时间，恢复点目标是最多能容忍丢失多长时间的数据。这两个数字是灾备体系的合同条款，向上承接业务的中断容忍度，向下决定灾备层次的采购。模型服务语境下要把数字翻译成业务语言：推理服务的恢复目标按服务等级分层——核心业务分钟级，长尾业务小时级；数据侧的重点分层——用户会话与对话历史可以容忍少量丢失并重建，计费与订单数据零容忍。定了数字就要验证：演练时实测恢复时间与数据完整性，与目标对照，差多少补多少。这两个数字不是汇报材料上的装饰，它们是灾备预算的分配依据：把最高的冗余投资花在最短的容忍度上。这两个数字还要与对外的服务承诺对齐：给客户承诺的可用性与赔付条款，内在支撑就是灾备与恢复目标——承诺高于能力，每一次故障都是违约现场。数字的设定顺序应当是从内到外：先按技术现实定恢复目标，再据此承诺服务水平，而不是反过来。

备份的有效性：备份不是存档

灾备讨论经常跳过一个更基础的问题：备份本身靠不靠谱。备份与存档的区别在于可恢复性：一份从未恢复过的备份，有效性是未知的。恢复演练要抽真实备份做真实还原——模型权重恢复后能加载、配置恢复后服务能起、数据恢复后校验一致；恢复流程的耗时也要实测，它直接决定故障时的真实恢复时间。备份还有自己的故障模式：恢复出来的版本太旧、备份任务静默失败数周无人发现、备份存储的权限失控导致备份被误删甚至被恶意加密。衡量备份体系是否健康，看三个数：备份任务成功率、最近一次恢复演练的日期、从备份恢复一套服务的实测耗时。三个数都拿得出来而且不尴尬，备份才算存在。

演练：不演练的预案等于没有

预案的最大敌人是纸面化。文档躺在知识库里，环境早已漂移，预案里写的备用模型三个月前就下线了，演练时才发现。演练是把预案重新接地的方法：桌面推演走决策流程，故障注入走技术链路，真实切换走完整流程。模型服务的高价值演练场景：主模型节点整体失联，验证自动切换到备用模型的时长与质量表现；依赖的向量数据库宕机，验证检索降级路径；区域级演练每年至少一次，真实把流量切到备区跑满一个业务周期。每次演练记录实际恢复时间与预案目标的差距，差距就是改进清单。演练频率的建议：核心链路季度级，全面演练年度级，每次大架构变更后加演一场。进阶形态是游戏日：设定一个复合故障场景——主区失联加备用模型版本错误，让团队在接近真实的压力下走完整决策链。游戏日的目标不是考核个人，而是暴露预案与现实的缝隙：哪里缺工具、哪里缺授权、哪里信息不通。一年一次的游戏日，抵得过十次纸面推演。预案的有效期只到下一次环境变更，演练是唯一能确认它还活着的方法。预案文档的组织方式也影响实战效果：灾难天没人有时间翻几十页文档，预案的一页纸摘要——故障判据、第一时间动作、关键联系人与升级路径——要能在半分钟内看完；详细文档给平时准备用，一页纸给事发现场用，两者都要有。

小结

灾备与降级的工程学，核心是把灾难天的决策提前到平时做完。起点是故障域分析：区域故障、依赖故障与模型版本事故三类各有炸法，产出一张「影响范围—检测手段—首要动作」的清单，其中模型版本的质量劣化最容易被传统监控漏掉，线上质量监控因此是灾备体系的一部分。灾备按三层建设：同机房冗余是无条件底线，跨机房解决机房级故障并要面对推理状态的取舍难题，跨区域为核心业务保留异地重建能力，模型制品与配置的异地副本是一切快速恢复的前提。降级是软件面的预案：备用模型、简化模式、静态兜底、排队限流构成阶梯，每级都要写清触发条件、执行权限与执行方式。恢复时间与恢复点两个数字是灾备的合同条款，按业务分层设定并靠演练实测校准。最后也是最重要的：预案的价值只在演练里兑现，季度级的核心链路演练与年度级的区域演练，是让它保持活着的最低成本方式。