点了十次，还是没结论

同事为了查一个慢的问题，连着点了十次测速，十条结果摆一屏，问我哪条是真的。

十条都是真的，但回答的都不是他要问的问题，白点了十次。

连测：用来排抖动

快，但只能回答稳定性，回答不了原因。

同一节点、同一时间、连续三次，看结果是否一致，成本最低也最快。

三次都差不多，说明这个数稳定；差很多，说明存在抖动，先别拿它下结论。

这一种最适合判断「刚才那个数字靠不靠谱」，也适合给别人演示。

间隔测：用来看波动和缓存

慢一点，但更接近真实体验，尤其对新用户。

隔几分钟甚至十几分钟再测，看数值是否回落或升高，波动幅度比单值更有意义。

短时间反复测，很多资源命中缓存，数字会偏乐观，跟新用户看到的不一样。

想反映首次访问的真实体验，就得让缓存过期再测，或者换一个干净环境。

跨时段测：用来抓高峰

费时间，但没有替代方案，高峰问题只能这样抓。

白天测一次、晚高峰测一次，同一组节点、同一条地址，两次才有对比价值。

很多问题只在忙时出现，白天怎么测都正常，这也是最容易漏掉的一类。

用宝塔拨测的网站测速配好固定节点，两次结果直接对比，差异很容易看出来，也不用来回解释口径。

记录要对齐

记录不对齐，三次等于一次，还浪费了时间。

三次的条件必须一致：节点、运营商、地址、是否带参数，少一样就没法比。

记录里写清时间、节点、状态码、五段耗时，别只留一个总数，总数什么都证明不了。

条件变了，就不是复测，是另一次测试，混着比会得出相反的结论。

复测能回答什么

知道它的边界，就不会用错，也不会对它有不该有的期待。

能回答：这个现象稳不稳定、影响哪些地区、变化发生在哪一段。

回答不了：为什么慢。那是分段和分组要解决的问题，别指望多测几次就能知道原因。

把复测当成验证手段，别当成诊断手段，位置摆对了，效率就高，也不会越测越乱。

模式选对，复测才真正省时间。

省时间，也不用跟人反复解释。

解释清楚，协作就顺。

顺了，判断也快。

判断快，处理就及时。

及时，损失就小。

损失小，业务才放心。

放心，才愿意继续用。

继续用，工具才有价值。

有价值，团队才会持续投入。

投入够了，体系才成型。

成型了，就不用每次从头摸索。

不用摸索，效率就稳。

稳了，才算真正的方法论。

方法论有了，判断就少走弯路。