一次失败的全貌，要看三段日志
故障排查最难的是把链路串起来 ✗：重试了几次 ✔、降级到哪一级 ✔、
最终返回给用户的是什么 ✔ —— 如果这三件事分别在三个系统里 ✔，就很难还原 ✔。
把"重试 + 降级 + 最终结果"用同一个 trace 串起来 ✔。
一、要串起来的六个事件
① 请求进入（trace_id 生成）
② 第一次调用失败（错误码 + 是否可重试）
③ 重试（第几次、等待多久、结果）
④ 降级触发（进入哪一级、为什么）
⑤ 兜底结果（是否命中缓存、是否规则兜底）
⑥ 最终返回（用户实际看到什么 + 是否标注了降级）
第 ⑥ 项最关键 ✗→✔：只有它记录了"用户到底看到了什么" ✔ ——
很多系统只记到 ④ ✔，事后无法回答"用户看到的是不是兜底结果" ✔。
二、三条实现要求
- trace 贯穿全链路 ✔（包括重试与降级分支 ✔ —— 见日志那篇 ✔）；
- 每段都记状态与原因 ✔（不要只记"失败" ✔ —— 记错误码与分类 ✔）；
- 降级与兜底必须留痕 ✔（哪个开关生效、哪条规则命中 ✔）。
三、四条"一次查询能回答"的问题
① 这次请求重试了几次？每次为什么失败？
② 有没有降级？降到哪一级？用户被通知了吗？
③ 最终结果来自模型、缓存还是规则兜底？
④ 这次请求一共花了多少（含重试成本）？
第 ④ 项常被漏 ✗：重试成本要算进这次请求 ✔（否则成本归因不到具体请求 ✔）。
四、三个反模式
- 重试日志与主日志分开 ✗（无法关联 ✔）；
- 降级只记"已降级" ✗（不记哪一级、为什么 ✔）；
- 兜底结果不标注 ✗（用户与复盘者都不知道 ✔ —— 见沉默失败那篇 ✔）。
五、一条判据
给一个"用户投诉答得不对"的请求 ✔，你能否在一次查询里看到"重试→降级→兜底→最终返回"的全貌 ✔？
不能，说明失败链路还没串起来 ✗。