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