技术复盘开发短记：怎样说明业务影响
复盘不该把技术指标直接翻译成业务收益。它需要分开写事实、推断和行动：监控与日志能证明什么，影响估算基于哪些假设，接下来谁负责修复和验收。这样读者才能判断结论的可信范围。
例如“错误率下降”是工程事实；“因此少损失多少订单”是业务推断，必须由已确认的流量、失败定义和转化模型支撑。缺少其中一项时，只报告受影响请求和已知用户行为，不要输出金额。
affected := duration.Seconds() * averageQPS * failureRatio // 这是估算；转化率与客单价必须由业务侧确认。反例是选取异常最严重的一小时外推全天，或把所有失败请求都按可转化订单计算。两者都会放大影响。若一定要估算，应写出时间窗口、分母、数据来源和不确定性，并明确它不能用于财务结算。
收尾要落在可验收的动作上：补哪条告警、增加哪个回归用例、何时检查数据修复、由谁确认。工程指标提供证据，业务分析说明取舍，两者之间的假设越透明，复盘越能经受追问。
写作前先对齐口径
复盘初稿应让监控负责人核对时间窗口，让产品或运营核对业务事件的定义。若日志采样、埋点缺失或统计口径中途改变，要在结论旁直接标注缺口。行动项不要写成“加强监控”，而要落到指标名、阈值负责人和复查日期。
发布后安排一次短回看：确认告警已接入、回归用例真的在流水线执行、遗留数据是否按约定处置。未按时完成的事项要说明阻塞原因和新的验收人，避免复盘沦为一次性文档。
这一轮回看也应留在原事件链接下，便于之后追踪。
如果影响范围只是估计值，标题和摘要同样避免写成已确认损失，防止片段传播时丢失限定条件。
