概念定义：容灾演练在AB页跳转语境下指什么
说白了，AB页跳转容灾演练就是在不碰真实投放主体的前提下，故意在跳转链路上搞点局部失效，看看系统能不能沿着事先定好的降级路径把分流和放行继续撑下去，最终确认业务连续性这个目标是不是真的能达到。它真正看重的东西是拿一个可控的坏消息去换对系统韧性的确认，"制造故障"本身倒不是重点。
跟日常监控比，差别在验证的方向上。监控回答的是"眼下有没有毛病"，演练回答的是"真出毛病了系统会变成啥样"。跟压测比呢，注入的对象不一样。压测压的是流量，演练注入的是组件失效、依赖中断、配置错误这一类结构性的坏情况。两者能搭着用，但谁也替代不了谁。
一次完整的演练，至少得凑齐四样东西：故障场景清单、注入手段、观测指标、复盘修复闭环。少一样，这事儿就退化成"点一下看看会不会炸"的随机操作了，拿不出能引用的结论。
机制与组成：故障注入怎么落到AB页跳转链路上
按层级来归，AB页跳转链路上的故障大概能分成四类，每类的注入方式和观测重点都不太一样。
决策层故障：规则引擎加载失败、规则版本回滚到错误快照、判定超时。注入一般是切规则源或者打延迟，观测重点在于超时之后默认分支有没有指向安全目标。；执行层故障：跳转中间件挂了、目标页返回5xx、重定向链路断掉。做法是摘实例或者返回错误码，重点看兜底页面能不能到、用户会不会看到一片空白。；依赖层故障：缓存不可用、IP库或设备特征库读不出来、下游判定服务超时。对依赖做熔断或限流来注入，重点盯降级之后判定准确率掉得是不是还在可接受区间里。；配置层故障：域名解析异常、证书过期、参数映射表错位。这类故障连复杂工具都不用，改一条配置就注进去了，可偏偏真实事故里最常见的也是它。。
注入手段与隔离要求
注入手段按粒度分三种：单实例注入、按流量比例注入、全链路注入。单实例注入风险最低，拿来验证兜底逻辑挺合适；按比例注入适合去摸降级阈值在哪儿；全链路注入就必须放到独立演练环境或者低流量时段，而且得配一个秒级回切开关。
隔离这块，是演练设计里最容易被省掉的一环。演练流量得可识别、可丢弃、可回滚。通常的做法是给演练请求打个独立标记，日志和计费链路单独归类，别让它们污染真实的转化归因数据。这一点做不到，演练结论就不可信——它跟真实流量的边界已经混在一起了。
观测指标怎么选
观测不能只盯一个指标，要看三条线是不是同时成立：跳转成功率的下限、兜底路径的到达率、决策耗时的分位值。成功率跌破预设下限，说明降级没接住；兜底到达率偏低，说明降级路径自己就有断点；决策耗时尾部分位拉长，说明超时预算设得不合理。三条线得一起看，只挑一条看，很容易得出错误结论。
适用条件：什么情况下该做、做到什么程度
前置条件是摆在那儿的。跳转链路得先有成文的降级预案，兜底目标、熔断阈值、回切步骤都写清楚。系统没预案就做演练，跟让它裸奔着暴露缺陷差不多，产出的是事故，不是结论。还有，演练环境和生产环境在配置结构上得一致，不然你验证的是另一套系统。验收口径也得提前定死，比如"决策层故障时，跳转成功率不低于某个水平且兜底页可达"。口径没有，通过与否就没法判定。
频次上，有三个时点是必须触发演练的：链路结构变更、新增依赖、大促前的窗口期。日常状态下，一个季度或者半年跑一次全场景演练就够了。高频演练会耗掉团队的注意力，边际收益一路往下走。
反过来讲，有几类问题别指望演练能解决。流量自然增长带来的容量不够，那是容量规划的事；规则本身的业务逻辑错了，那是配置评审的事；第三方服务商长期不稳，那是供应商评估的事。演练能把这些问题暴露出来，但替代不了对应的治理动作。把演练当万能药，结果就是每回演练都发现同样的问题，修复却不在演练流程里完成。
边界与对比：与相邻概念的决策分界
与混沌工程的边界
混沌工程是更宽的一套方法论，讲究在生产环境里持续做小剂量实验，用实验去发现未知的失效模式。AB页跳转容灾演练的范围窄得多，目标是验证已知的降级预案到底有没有效，一般放在有隔离保障的环境或者受控窗口里跑。一个偏探索，一个偏验收。团队规模有限的时候，先把验收型演练做扎实，再往探索型实验那边演进。
与灰度发布、回滚演练的边界
灰度发布管的是"新配置逐步放量"，回滚演练管的是"变更之后能不能退回去"，这俩都围着变更转。容灾演练围着的是"不变更的情况下组件失效"，注入的是外部故障，跟版本差异没关系。三者能串成一条链——灰度控放量、演练验兜底、回滚保退路，但各自的验收标准不同，不能合并成一次动作。
前年接触过一个做工具类软件投放的团队，日均点击一千二三百，链路是规则引擎加一层中间件再加目标页，服务器规格不算高，两台中配实例加一个缓存节点。他们头一回演练挑的是把缓存节点直接摘掉，结果发现规则引擎在缓存不可用的时候会同步回源去读特征库，回源耗时把决策延迟拉到了接近超时阈值，兜底分支被大量触发，跳转成功率掉得比预想严重得多。
问题出在超时预算和回源并发没有联动设计上，缓存本身倒没什么毛病。调整分两步走：先给回源加了并发上限和本地短时缓存，再把决策超时预算从单一值改成按分支分级。第二次演练同样的注入，跳转成功率稳在可接受区间，兜底触发比例明显收敛。这个案例说明，演练暴露出来的往往不是你注入的那个组件，而是它旁边的耦合关系。
概念性问答
演练必须停掉真实流量吗
不用。按比例注入再加上请求标记隔离，大部分场景验证都能在真实流量还在跑的情况下完成。只有全链路注入这类高影响场景，才需要低流量窗口或者独立环境。关键看隔离手段到不到位，流量是不是零并不重要。
演练通过是否等于系统不会出问题
当然不等于。演练验证的是已经建模的故障场景和已经定义好的降级路径。没建模的故障、复合故障，还有降级路径自身的缺陷，照样可能在真实事故里冒出来。演练的产出是一份"已知场景下的能力确认"，它给不了免疫证明。
没有专职运维的小团队要不要做
要做，范围缩小就行。从配置层故障和单实例注入入手，这两类不需要什么复杂工具，改配置、摘实例就能搞定，验证的是兜底页可达和回切步骤有效。范围小但闭环完整，比那种大而空的演练计划有价值得多。
落地要点：让演练产出可复用的结论
演练记录得能回答三个问题：注入了什么、观测到什么、修复了什么。这三者对不上，这次演练就白做了。格式上建议按场景一条一条写，每条包含注入手段、预期表现、实际表现、差异原因、修复动作和责任人。这份记录本身就是下一次演练的基线，故障排查的时候也能当参照。
修复动作必须回流到配置和预案文档里。演练发现兜底页不可达，改完兜底配置就得同步更新预案；发现超时预算不合理，调完参数就得写进配置基线。演练没带来文档变更，等于没发生。把这条当成硬性要求，容灾演练才会从一次性动作变成持续的能力沉淀。
