估算一次改动的风险面
列出谁会被影响、哪条链路最脆，以及出事后怎么退
你是这次改动的反对者，任务是找出它可能伤到谁。根据下面的改动说明和系统依赖，输出：1）受影响的调用方、数据、定时任务和下游，逐个说明影响方式；2）按「影响人数 × 恢复难度」排出风险最高的三处；3）指出这次改动依赖但未验证的假设；4）给一份上线顺序和回退方案，包含判断回退的指标阈值。不要用「影响可控」收尾，要给具体证据。 [改动 diff/依赖关系/流量规模]
使用建议
先找「读这份数据但不归你维护」的消费方；最容易被漏掉的永远是旁路脚本和报表。
适合什么场景
- 要改一个共享字段的单位，或者改 API 返回结构，而各客户端的上线节奏并不一致。
- 要删除或重命名一个配置键，而好几个服务在间接读取它。
不适合的场景
- 全新功能、还没有调用方：影响面是空的，精力应该花在别处。
- 内部重构、契约没有变化：风险是局部的，测试已经覆盖。
示例
输入
diff: 将 /api/orders 返回的 `amount` 从元改为分；同时把 orders.amount 列类型 INT 改为 BIGINT。 已知：移动端 2 个版本仍在线上，财务日报每天 01:00 读该表。
你会得到
风险最高的是旧版移动端：单位从元变分不会抛错，只会把 19.9 元静默显示成 1990 元，错误率监控抓不到。其次是财务日报：列类型从 INT 改 BIGINT 可能破坏它的解析或精度假设，而且 01:00 没人盯着。回退必须同时覆盖 API 返回和列类型，判断阈值应设成「出现金额相关客诉或日报校验差异 > 0.01%」，而不是等 5xx 上升。
常见误用
- 只评估自己负责的服务：真正被伤到的是读同一张表的报表和旧客户端。
- 把「有回滚脚本」当成风险可控：如果数据已经按新单位写入，回滚代码也回不去。
可以这样改
- 加「找出一个这次改动不应影响的重叠功能作为对照」，能验证你的影响面分析不是全量恐慌。
- 要求「给每个受影响方一个可观测信号」，风险就从清单变成上线后能盯的指标。