一个团队为"选两个消息队列"做了三周实测：搭环境、写脚本、跑三轮、写报告。结论是"A 的 P99 低 12%"。而三个月后他们又改回 B——因为"A 的运维复杂度"三周里没人量过。
实测的成本有两种："跑测试的时间" 与 "结论出错后的返工"。前者容易估，后者常被忽略——而它才是"实测"真正的开销.
1. 一次实测的四段成本
| 段 | 典型人时 |
|---|---|
| 环境与脚本 | 8–24 人时 |
| 跑与观察 | 4–8 人时 |
| 分析与报告 | 4–8 人时 |
| 结论返工（若结论错） | 20–200 人时 |
第四项是"杠杆"："省 10 人时"的偷工，可能换来"100 人时的返工".
"实测的立项"应当先写"三行"，否则"跑起来就没边":
// 三行立项（十分钟）
问题：A 与 B 在"我们的负载"下，P99 与运维成本谁更优？
判据：P99 差 < 10% 视为"无差异"，此时看运维成本
预算：16 人时（超过就"降级为粗测 + 先用再评估"）
// 判据：写完三行，能立刻判断"这次实测要不要做"
2. "结论返工"的三种来源
| 来源 | 例子 |
|---|---|
| 漏了关键维度 | 只测吞吐、没测运维复杂度 |
| 测法与生产不符 | 单机压测、生产是集群 |
| 数字在噪声内 | 12% 差异小于方差 |
第三项最"贵"："基于噪声做的决策"会"在半年后被迫重做".
"人时"要"按段估"，而不是"估个总数":
// 一次"中决策"实测的分段预算（20 人时）
环境与脚本 8（可复用部分：5）
跑与观察 4
分析与报告 4
预留返工 4（"结论可疑"时的重跑）
// 判据：任一段"超预算 50%"就"停下来重新立项"
3. "该花多少"的三档
| 决策影响 | 建议投入 |
|---|---|
| 小（可替换、低耦合） | 4–8 人时 |
| 中（影响一个服务） | 20–40 人时 |
| 大（平台级、多年） | 80+ 人时 |
第二项是"多数场景"："一个服务用哪个库"——不值得"三周"，但值得"两天".
"先筛后测"的收益最大，而"筛"只需要"外部分信息":
// 三步"筛"（4 人时）
1 读官方 benchmark 与 issue：排除"已知的坑"
2 一次"粗测"（单机、1 分钟）：排除"数量级不符"
3 找"用过的人"问一句：排除"运维地狱"
// 判据：三步筛完，通常只剩 1–2 个候选需要"精测"
4. "省时"的三种正确做法
| 做法 | 省什么 |
|---|---|
| 先"筛掉明显不合适的" | 不必精细测 |
| 复用"现成的压测脚手架" | 环境与脚本 |
| 只测"决策相关的两个指标" | 分析 |
第三项的"判据"是"这个指标变了，决策会变吗"：不会变的指标，测它只是"报告里多一行".
第三项是"最有效"的："决策"通常只依赖"一两个指标"——**其余是"心理安慰".
"防返工"最便宜的动作是"列未测项"，而它只要一分钟:
// 一份"报告头"（五行，值一千人时）
结论：A 的 P99 低 12%（区间 [8%, 16%]，噪声 ±6%）
测法：3 节点集群，10KB 消息，1 小时稳态
未测：运维复杂度、故障恢复、社区活跃度
建议：若"运维成本"权重高，本次结论不足以下决策
// 判据：读者"只读这五行"就能判断"能不能用"
5. "别省"的三种投入
| 投入 | 为什么 |
|---|---|
| 写清"问题定义" | 否则测的不是那个问题 |
| 先测"噪声幅度" | 否则分不清差异 |
| 记"未测的维度" | 否则结论被误用 |
第三项很实用：报告里写"未测运维复杂度"第三项的"写法"要"具体"："未测：运维复杂度、故障恢复时间、社区活跃度"——**而不是"本测试请谨慎对待".
——**于是"读报告的人"不会"把它当成全结论".
"反复重测"的根因通常是"没固化"，而固化只要"三个文件":
// 三个"可复用"的产物
1 bench/run.sh → 一条命令跑完（含预热与采样）
2 bench/data_gen.py → 固定种子生成输入
3 bench/RESULT.md → 结论 + 测法 + 未测项
// 判据：下一个人"不用问你"就能重跑
6. 排错：五种"实测成本失控"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 测了三周没结论 | 问题定义不清 | 先写"判据" |
| 结论被推翻 | 漏关键维度 | 列"未测项" |
| 数字对不上 | 测法不符生产 | 对齐环境 |
| 反复重测 | 无脚本/无记录 | 固化脚手架 |
| 没人看报告 | 太长/无结论 | 一页结论 |
"先用再评估"要"可控"，否则它变成"埋雷":
// 三步"先用再评估"（可逆才成立）
1 选"可替换"的那一层（接口隔离，能换回）
2 设"观察指标"（错误率、P99、运维工时）
3 定"复盘时间"（如 4 周后）
// 判据：换回来的成本 < 1 人日，才可用这招
7. 边界：什么情况"不做实测"更划算
| 场景 | 为什么 | 做法 |
|---|---|---|
| 差异"量级级"（10 倍） | 不必精确 | 粗测/查资料 |
| 决策"可逆且便宜" | 错了就换 | 先用后评估 |
| 已有"公认基线"（官方 benchmark） | 复现成本高 | 引用 + 小验证 |
| 团队"没有压测能力" | 测了也不准 | 先建能力 |
最后一条与"组织"有关的边界："压测能力"是"复用资产"：一次投入"脚手架 + 脚本 + 数据生成"，后续每次实测"省一半"——于是"值不值得测"的答案会随"能力成熟度"变化，而不是固定结论.
判断口径一句话："这个决策错了，返工要多久"**。返工很久（平台级、数据迁移），实测值得"几十人时"；返工很轻（换一个库、改一行配置），"两天粗测 + 先用再评估"更划算.
再补一个"隐性成本"："实测"会占据"最懂系统的那个人"的时间——而他的时间本来用来"修线上问题"。所以"实测"的真实成本不只是"人时"，还有"机会成本"：三周实测期间，那个 P0 故障没人能定位。这也是"值不值得测"里最容易被漏的一项——而它的量级，往往比"人时"更大。
还有一个"决策"现实值得写进结论："实测"常常被用来"支撑一个已经做出的决定"——于是"测什么、怎么测"会不自觉地"朝结论靠"（选对指标、选对负载）。这不是"造假"，而是"确认偏差"：你只想验证"我选对了"。 防御手段很轻：立项时把"判据"写成"什么情况下我会改主意"——**如果写不出"改主意的条件"，那这次实测就不是"测"，而是"背书". 而"背书"的成本最低、收益也最低：它花同样的三周，却不产生任何"可能改变决定"的信息。
再补一条"复用"建议：把"实测"的产物存成"可检索的资产"——脚本、数据生成器、结论、未测项。因为"同一个问题"通常"一年后被重新问一遍"（换人、换场景）；而"有资产"时的成本是"半天"，"没资产"时是"两周"。所以"实测"的价值不只是"这次的结论"，还有"下次的起点"——而这一点在"立项"时几乎从不被算进预算。
而"存资产"的成本，只是"把三个文件放进仓库"。
而"半天 vs 两周"这个差距，会随"团队规模"放大：十个人各问一次，就是"五天 vs 二十周"。
所以"资产化"不是"整洁"，是"省下一整轮的重测"。
而"什么情况下我会改主意"这一句，值得写在报告的最后一页。
8. 自测
- 实测的四段成本里，哪一段是"杠杆"？为什么"省 10 人时"可能换来"100 人时"？
- "结论返工"的三种来源里，哪一种最"贵"？它为什么会"被迫重做"？
- "该花多少"的三档分别对应什么决策影响？
- "只测决策相关的一两个指标"为什么最省？
- 为什么"记未测的维度"能防止结论被误用？
- 判断"要不要做实测"的那个问题是什么？