主路径全绿就上线？降级链路才是事故高发地：一份可验收的第三方依赖降级清单

结论先行：我们以为"功能上线"的判据是主路径 100% 通过，但真正出事故的几乎全是降级路径——因为降级路径平时不跑，代码在腐化，验收单上也没人验证它。这篇文章给一份可以直接抄进验收单的"降级链路验收清单"，并附上我踩过的 4 个坑。

一、现象与背景：降级路径是"平时不跑、出事必跑"的死角

先看一组真实数字。我所在的团队对外依赖 3 个第三方服务：短信网关、支付渠道、物流查询。过去 12 个月我们复盘了 7 起 P1/P2 事故，其中 5 起（71%）与"降级路径"直接相关：

• 短信网关超时 3s，我们的"降级到邮件"分支里那行 emailTemplateId 在 3 个月前重构时被删掉了，邮件发不出去，用户收不到验证码，客诉 4 小时涨了 80+；
• 支付渠道限流返回 429，我们的"稍后重试"提示文案写死了"渠道故障"，被用户截图发微博，公关介入；
• 物流查询接口 5xx，我们直接返回"查询失败"，但用户此时已经下单完成，体验断裂点恰好卡在下单成功那一刻。

更扎心的是：这 3 个降级分支的单元测试覆盖率都是 0。主路径全绿、CI 通过、上线评审签字——但降级路径根本没被验证过。

我把这个现象叫"降级路径的静默腐化"：它不像主路径那样天天被流量冲刷、被用户反馈、被监控盯住，它只在第三方出事的那一刻才露面，而那一刻往往已经晚了。

二、原理与根因：为什么降级路径特别容易烂

三个机制叠加：

1. 执行频次不对称。 主路径每天被几万次流量跑，任何 bug 都会在监控大盘上冒头；降级路径一年可能只跑个位数次，bug 可以静默存活 6 个月没人发现。这是"平时不跑"的直接后果。

2. 状态机不对称。 主路径通常是有状态的（下单 → 支付 → 发货），每一步都有业务对象；降级路径常常被写成"无状态直接拒绝"——直接返回错误文案、直接抛异常、直接 fallback 到空数据。无状态意味着没有验收锚点，测试用例很难写，评审时也容易被跳过。

3. 代码所有权不对称。 主路径是业务开发写的，业务开发懂；降级分支常常是"顺手写一下"的兜底，甚至可能是上一任同事留下的死代码。没人对它负责，等于没人对它负责。

所以根因一句话：降级路径是"高影响 × 低频次 × 弱所有权"三者叠加的死角，验收单如果只卡主路径，等于把最大的风险敞口留在外面。

三、具体做法：把降级验收固化成一张"降级矩阵"

我在验收单里强制加了一张降级矩阵，每个第三方依赖必须填全 4 列，缺一列 = 不能上线：

依赖: 短信网关
故障类型枚举: timeout / 5xx / 429限流 / 数据格式错误 / 连接失败
触发条件(量化):  连续 5 次超时 或 P99 > 2s 持续 30s
用户可见行为:   降级到邮件 + 短信补发队列，提示文案 "验证码已发送至邮箱"
可恢复性:       自动回切，回切 SLA ≤ 60s，回切后 5 分钟监控无异常

配合三条可执行动作：

动作 1：故障注入演练（不是 mock，是真注入）。 在预发环境用 sidecar 或故障注入中间件（Chaos Mesh 的 NetworkChaos / IOChaos，或直接给短信网关代理层配 5s 延迟）真实打一遍降级路径。判据：

• 降级期间主功能 5xx 率 ≤ 基线 1.5 倍；
• 降级提示文案 100% 命中（用 curl 脚本断言响应体包含目标字符串）；
• 自动回切时间 ≤ 60s（演练脚本记录时间戳）。

动作 2：降级路径独立测试用例，覆盖率单独统计。 不允许"降级分支搭主路径的便车"。每个降级分支必须有独立 case，且独立 case 覆盖率 ≥ 80%，进 CI 门禁。

动作 3：演练留档 + 每半年一次。 每次演练生成一份报告（故障注入配置、触发时间、降级行为截图、回切时间），归档到 runbook。半年不做一次演练 = 降级路径视为不可用，下次上线评审一票否决。

四、踩过的坑（4 个，按翻车程度排序）

1. mock 网关 ≠ 真实故障。 我们用 mock 做验收，mock 返回即时 500，代码路径走"5xx 分支"；但真实故障常常是超时（3s 半开连接）或部分成功（网关收到但渠道没发），走的是完全不同的代码分支。结论：mock 只能验"逻辑对"，不能验"故障形态对"，必须至少有一类用真实注入。

2. 降级了，但回切不自动。 这是我们最痛的一次：降级状态机里加了"降级中"，但没加"恢复中"。第三方恢复后，我们的服务还停在降级态，用户持续收到"渠道故障"提示，直到有人手动重启服务。回切必须自动化，人工回切要写进 runbook 并演练过——否则就是"降级成功、恢复失败"的半吊子。

3. 降级提示文案写死，没做 i18n 和场景化。 "渠道故障"四个字被用户截图传播。文案验收要进矩阵：文案由配置中心下发、按场景（下单中/下单后/未下单）分版本，验收时断言文案字符串，而不是"提示用户稍后重试"这种模糊判据。

4. 验收单上写"降级功能可用"等于没写。 这种判据无法被证伪，评审时人人点头。必须量化成 5xx 率、文案命中率、回切时间三个可测数字——我前文 LLM 验收那篇讲过同样的道理，"done"的定义必须是可断言的，否则就是没有 done。

五、结论与可复用清单

一句话总结：降级路径是"高影响 × 低频次 × 弱所有权"的死角，验收单只卡主路径等于把最大风险敞口留在外面。

可直接抄的清单：

[ ] 每个第三方依赖：有降级矩阵吗？（故障类型 / 触发条件 / 用户行为 / 可恢复性 4 列填全）
[ ] 每个降级分支：有独立测试用例吗？独立 case 覆盖率 ≥ 80%？
[ ] 每个降级路径：有故障注入演练记录吗？最近一次演练在 6 个月内？
[ ] 回切：是自动的吗？回切 SLA 是多少？人工回切写进 runbook 了吗？
[ ] 降级提示文案：由配置中心下发吗？按场景分版本吗？验收时断言字符串了吗？
[ ] 降级状态有独立监控大盘吗？（不能复用主路径大盘，否则降级时监控是"绿的"）

最后补一个反直觉的提醒：降级路径的监控不能复用主路径的。主路径大盘看的是"成功率"，降级路径看的是"回切时长"和"降级占比"——两个指标方向相反。我见过一次降级触发后，主路径成功率反而上升了（因为慢请求被快速拒了），大盘一片绿，值班同学以为一切正常，直到客诉打进来。

核心一句话：主路径全绿只是"能上线"，降级路径全绿才是"敢上线"。前者靠 CI，后者靠演练——而演练这件事，验收单上必须有一栏专门卡它。