每周性能技巧 #88：测量方法：避开软糖豆陷阱
本节阅读量:本文翻译自 Abseil 官网的 Performance Tip of the Week #88: Measurement methodology: Avoiding the jelly beans trap。
原文发布于 2024 年 12 月 3 日，作者 Chris Kennelly，更新于 2025 年 7 月 16 日。
性能工作经常需要比较“修改前”和“修改后”。本篇讨论如何避免因为反复尝试、选择性报告或测量噪声而得出错误结论。
软糖豆陷阱
经典漫画展示了这样一个场景：研究者测试不同颜色软糖豆和某种结果之间是否有关联。大多数颜色没有显著结果，但绿色软糖豆恰好出现了显著差异。问题在于，如果我们测试足够多颜色，总会有一个看起来显著。
性能分析也会遇到同样陷阱。如果我们尝试许多指标、许多子集、许多时间窗口，最终很可能找到一个看起来支持某个故事的图表。这个结果可能是真实信号，也可能只是噪声。
预先写下假设
在开始测量前，写下你期望看到什么，以及它会如何改变决策。这样做可以减少事后挑选数据的诱惑。
例如：
- 这个改动应该降低服务整体 CPU。
- 它可能增加内存使用，但增幅应该小于某个阈值。
- 它不应该让延迟尾部变差。
- 如果负载测试没有显示至少某个幅度的收益，就不继续推进。
预先定义成功标准并不意味着不能探索数据。探索很有用，但探索性发现应该被视为新假设，需要用独立数据重新验证。
控制多重比较
当我们查看许多指标时，应该预期会出现一些偶然显著结果。解决方式之一是减少关注指标数量，把注意力放在真正会改变决策的指标上。
另一个方式是使用独立验证。第一次观察到的异常可以帮助生成假设；第二次、在不同时间窗口或不同工作负载上看到同样结果，才更能增加信心。
选择合适窗口
性能会随时间变化。昼夜流量模式、发布节奏、批处理任务和数据中心状态都会影响指标。如果只选择对自己有利的窗口，就可能高估收益。
使用完整、代表性的窗口通常更好。若必须排除某些时段，应该在查看结果前定义规则，例如排除已知事故或部署不稳定期。
报告负面结果
负面结果也很有价值。它们能帮助团队学习哪些方向不值得继续，防止别人重复同样实验。
只报告成功案例会让优化过程看起来比实际更确定，也会导致过度自信。记录失败原因、测量方法和后续假设，可以提高未来项目质量。
结语
好的测量方法不是为了让结果显著，而是为了让结论可靠。预先定义假设、控制多重比较、使用代表性窗口，并愿意报告负面结果，可以帮助我们避开软糖豆陷阱。
