自己测着挺快，客户说慢

客户投诉访问慢，我在公司测了一遍，两百毫秒，挺正常。

来回几次谁也说服不了谁。直到我跑了多节点，才看见某家运营商晚高峰明显掉速，问题根本不在我们这边。

判断标准只有一条

这一条判断对了，后面就顺了，也能省下不少预算。

问题是不是随来源变化。

换个地区就正常，换个运营商就变慢，那问题跟来源有关，值得上多节点。

在哪测都一样慢，那问题跟来源无关，多节点帮不上忙，只会浪费节点额度。

宝塔拨测控制台：定时拨测任务、节点与告警配置

宝塔拨测控制台：定时拨测任务、节点与告警配置

值得用的几种

这四种情况，多节点几乎是唯一解，单点怎么测都说不清。

只有部分地区反馈慢，需要确认范围，别拿一个点当全国。

怀疑某家运营商互联质量差，需要对比分组结果，这类问题单点测不出来。

上线前做验收，需要证明各地都能正常访问，这是最省事的保险。

出故障后要证明已经恢复，需要多地同时复测，一次单点结果没法交差。

不值得用的几种

这几种情况，测了也不会更清楚，只会让人更累。

服务端处理慢，所有请求都排队，多节点只是把同一份慢重复几十次，看着热闹没有信息。

自己本地网络有问题，测哪都不对，先换网络再谈检测。

一次性偶发，没有第二次，先记录再观察，不必大动干戈，也不必发通报。

怎么用才不浪费

节点不是越多越好，覆盖对了才有用，堆数量是给自己找麻烦。

先把节点范围定下来，覆盖主要省份和主要运营商，别只挑离自己近的。

用宝塔拨测的控制台配成固定任务，别每次临时建，临时建的结果没法横向对比。

结果按运营商和地区分组看，别只看一个平均值，平均值会把问题抹平，两极分化的时候最明显。

跟监控接上

一次检测回答现在，监控回答一直，两个问题分开问。

检测是手动的快照，监控是持续的记录，前者解决疑问，后者防止遗忘。

把关键域名加进去，设好告警阈值，出问题时不用从头查，时间就是钱。

两者配合，才谈得上「早发现」，只靠人工巡检永远慢半拍。

先判断问题性质，再决定要不要开测。

判断错了，测再多也只是自我安慰。

这句话值得写在墙上，省下很多无用功。

省下来的时间，够做很多正经事。

这算是运维的性价比思维。

值得花时间的一直是人，不是工具。

工具只是把手，判断还是自己。

把判断练出来，工具才用得顺。

顺了之后，很多事就没那么费劲了。

这句话，我用了好几年才想明白。

想明白之后，动作就简单了。