结论先行：试点选哪些服务，不是「先接几个看看」这么随意的事。它决定了验证期结束时，你手上是一堆漂亮的曲线，还是一个能让开发和业务都点头的结论。挑试点有四条判据：真实调用量够、跨团队调用多、有已知的慢点或故障史、上下游都在纳管范围内。四条中只满足一两条的服务，接上去也证明不了什么。

试点要的不是「装上能看」

监测平台在演示环境里都能看得见东西，所以「装上去有数据」这件事本身没有说服力。试点真正要回答的是一个具体问题：这套东西在这个环境里，能不能定位到我们现在定位不了的那一类问题。

问题定不下来，试点就会变成一次安装验收，而不是一次能力验证。

四条判据

判据为什么重要怎么核
真实调用量够量太小的服务，采样后样本不足，耗时分布没有参考价值取近两周的日均请求数，而不是看接口数量
跨团队调用多跨团队的调用链最容易出「各说各话」，也最能体现链路价值看这条链路牵涉几个团队、几个系统，至少跨两个
有已知的慢点或故障史有历史对照，结论才可验证，不用等下一次故障翻近半年的故障记录与慢查询工单，挑出可复现的一两件
上下游都在纳管范围内只接中间一段，链路一断就说不清，结论也落不了地把这条链路的入口、下游依赖、外部调用列全，确认都能采到

三类不适合做试点的服务

  • 调用量极低的。一天几百次调用的内部系统，采样之后几乎是空的，任何结论都不成立。
  • 只有单个团队自用的。没有跨团队争议，链路的价值体现不出来，验证完也很难推广给别人。
  • 本身就要下线的。投入适配的时间会白花，而且试点期的数据没有后续参照。

试点期要拿到的三样东西

其一，一次完整的跨服务链路。从入口到下游，中间的异步调用、外部依赖、缓存都要在同一条链上，断开的地方要在报告里写明原因。其二，一次真实故障的回溯。拿一次历史故障的时间点，把当时的调用链、耗时突变、异常堆栈还原出来，和当时的排查记录对得上。其三，开发侧认可的一次定位结论。这件事最难，但没有它，试点结束时就只有运维一方说好。

三个失败信号

验证期过了一半，还说不清「这次试点要证明什么」；采到的数据里，关键链路的断点一直没修；业务方与开发方到复盘时才被通知。任何一个出现，都值得停下来重新定范围。

边界与前提

这四条判据适用于分布式架构、服务数量在几十个以上的环境。单体应用为主、调用关系简单的环境，判据要相应简化，重点改成「有没有可对照的历史故障」。另外，试点范围与探针部署方式、平台的授权容量是两件事，不能混在一个决策里做。

本文只谈试点阶段挑哪些服务，不谈探针怎么部署、也不谈平台按什么规格选型，这两件事的评估依据与本文不同。

深圳市奇摩计算机有限公司在推进监测接入时，会先和客户一起把试点清单与服务归属人定下来，签完这一页再动手装探针，避免验证期过完才发现选错了对象。

如果正在准备接入，建议先把近半年的故障记录翻一遍，试点对象往往就藏在那几件事里。 预约咨询