没演练过的降级链，等出事时大概率不生效
（标题说明：这里说的"演练"，指主动断开上游，看系统是否按设计的降级链逐层生效 ✔。）
多数团队的降级链只存在于设计与代码里 ✗，从没在真实环境跑过一次 ✔。
真出事时才发现：某个降级分支有 bug ✗、缓存没预热 ✗、开关不生效 ✗、提示文案缺失 ✗。
至少每季度做一次"断上游"演习 ✔。
一、演习前：明确四件事
- 演习范围（哪个功能、哪条上游 ✔ —— 先在预发做，再在生产做小范围 ✔）；
- 预期行为（逐层：重试 → 小模型 → 缓存 → 规则兜底 → 明确不可用 ✔）；
- 观测方式（看哪些指标、谁盯 ✔）；
- 回退方式（怎么立刻恢复 ✔，以及谁有权决定回退 ✔）。
二、演习怎么做（六步）
① 选一个低峰时段，通知相关人（避免误判为真事故 ✔）
② 断开上游（改路由/封端口/切开关 ✔）
③ 观察：降级是否按预期触发？用户看到什么？指标如何变化？
④ 记录：每一层的触发时间、耗时、用户可见文案 ✔
⑤ 恢复上游，观察是否自动恢复（而不是需要重启 ✗）
⑥ 复盘：把发现的问题变成待办（含验证方式 ✔）
第 ⑤ 步很重要 ✗：很多系统"能降级但恢复不了" ✔（熔断不半开、连接池没重建 ✔）。
三、该验的六个点（可直接抄）
□ 降级触发是否及时（不要等到超时才降 ✔）
□ 降级后用户看到的提示是否可行动（见降级提示那篇 ✔）
□ 缓存/兜底路径是否真的可用（不是"理论上可用" ✔）
□ 成本是否受控（降级不应更贵 ✔）
□ 恢复是否自动且快速 ✔
□ 全程有日志与指标（事后能复盘 ✔）
四、演习之外：把"可降级"做进日常
- 每月看一次降级触发率 ✔（长期为 0 说明要么没降级要么没观测 ✔）；
- Kill switch 每季度手动关一次（见灰度开关那篇 ✔）；
- 把演习写进值班交接 ✔（新人第一周就知道怎么做 ✔）。
五、两个反模式
- 演习只做"开关切换" ✗ → 没验真正的上游故障（超时、限流、部分失败 ✔）；
- 演习后不写待办 ✗ → 下次演习还是同样的问题 ✔。
一条判据
如果今天上游全挂 ✔，你能否在 5 分钟内说出"用户会看到什么、成本会怎样、谁来决策回退" ✔？
说不出，就该安排一次演习了 ✗。