拨测系统选型，别让哨兵自己先瞎了

拨测系统，说穿了就是一群分布在不同位置的“假用户”，按你的要求去访问业务，然后把结果报回来，它解决的核心问题不是“现在挂了没有”，而是“从某个地方、某个运营商、某个时段看，到底哪里有问题”。

拆开看，一个拨测系统就三块：节点端、控制端、数据端，节点端决定你“站在哪儿看”；控制端决定“怎么看”，包括频率、协议、脚本编排、灰度策略；数据端决定“看完了怎么认”，包括耗时拆解、可用率计算、告警收敛，很多人把拨测系统等同于“定时 curl”，这是误区，curl 能告诉你 200 还是 500，但给不了 DNS 解析时间、TCP 建连时间、SSL 握手时间、首包时间、下载时间，CDN 调优最需要的就是分段耗时，不然你分不清是用户边缘网络差,还是节点回源慢。

再说方案对比，自建拨测，听起来自由，做起来是坑，用 Prometheus blackbox exporter 加 Grafana，确实能搭出一个能用的拨测系统，但节点不够、被墙、定时任务扎堆导致源站被打、数据要自己修，这些事会耗掉一个小组，商业 SaaS 省心，节点多、支持真实浏览器，但价格按拨测次数走，量上来后账单同样感人，而且拨测数据出网在一些政企场景过不了合规，云厂商的拨测产品则胜在开通即用，和云监控、日志服务打通，但你拨的是“云上视角”，对 CDN 边缘节点覆盖往往不够细，想拨到某个二三线城市的特定运营商,得看厂商脸色。

对比下来，没有绝对好坏，自建适合节点资源丰富的 CDN 厂商，因为你自己的边缘节点就是天然拨测源；SaaS 适合业务线多但不想养平台的团队；云拨测适合上云较深、对最后一公里不敏感的业务。

拨测系统选型，别让哨兵自己先瞎了

分场景讲：如果是为了盯核心业务可用性，5 分钟一次就够了，别设成 10 秒，那不是拨测，是对源站的 DDoS，如果你是 CDN 运维，要评估边缘节点质量，那拨测必须覆盖各省各运营商，且要能拨到“用户所在的小区”，最好有下沉节点，如果是为了发版回归，你需要编排能力，比如先拨测试环境，再拨灰度环境，最后拨生产环境，这条路最好用 SaaS 或自建平台，别用一堆 cron 脚本，如果是做竞品分析，得用真实浏览器内核，别用 curl，因为很多页面是 JS 渲染的。

我的选型建议是：别先看功能列表，先回答三个问题——你要拨什么协议？你要从哪看？你拿到结果要做什么？协议决定支持矩阵，位置决定节点分布，归因决定数据模型，对 CDN 场景，至少要能区分“用户到边缘节点”和“边缘节点到源站”两段质量,不然拨测结果就是一笔糊涂账。

另一个容易被忽视的是拨测任务本身的调度，多个拨测节点同时发起，会造成流量尖峰，轻则告警误报，重则把源站打挂，好的拨测系统要有时间抖动、分片调度、重试退避，这些设计比好看的报表重要得多，选型时一定要问：你的调度器是全局统一还是节点自治？节点自动摘除是否及时？

别迷信大而全，拨测系统是解决问题的工具，不是 KPI 装饰，先用最简单的方式解决最疼的问题，再逐步加复杂度，如果哪天你发现拨测系统自己挂了，而业务还好好的，说明你的监控比业务更脆弱，这句话,值得写进每一份拨测系统选型方案的扉页。