慢，会影响用户体验，随着业务的发展，如果不关注性能问题，整个接口会朝熵增的方向恶化，可能会越来越慢。

一般重点关注 Top10 的慢路由，可以分析是长期慢，还是突发抓取的慢，结合 APM 链路分析，整个请求慢在哪，是依赖中间件慢还是请求路径过长抑或是存在其他慢风险。这部分依然可下钻到”NO5.路由详情分析“，”NO6.抓取分析“。

5、路由详情分析

这部分依然在做问答题，主要是围绕给定的 route_name 展开分析的。

• code 分布是否具有显著差异性，如 P99 时延增加了，可能是缓存命中率 code=304 过低了。

• 同比环比是否具有差异性？尤其是周期性存在明显波动，或突发波动的会被优先怀疑。由于是在分析具体的路由，首要怀疑是否有线上变更，如图中 P99 具有显著差异性，是因为当天业务有修改线上配置造成的。结合链路分析慢的问题，最终优化了链路请求解决了这个问题。

• 是否是抓取造成的？另外一个常见的异常是由于蜘蛛突发抓取造成的，为了资源最大利用率，一般不会冗余过多的机器，当蜘蛛突发抓取冷数据的时候可能会造成波动。这部分主要是分析 UA，为了避免 UA 过长带来的分析性能损耗，采用了 hash ua 的方式。结合 ua 占比，ClientIP 占比，评估是否存在抓取的可能，具体可以下钻到”NO6.抓取分析“。

• 是否存在地域差异性？如北京用户异常占比过高，可能是北京链路出现了异常。

• 异常分布运营商节点是否存在显著差异？比如腾讯回源造成缓存穿透。

• 异常分布在后端节点上是否具有显著差异性？从而判断是否存在机器问题。这部分可以继续往机器的维度下钻，分析是 CPU 或其他资源异常。

• 如果以上常见场景都没命中，可以分析客户端相关信息是否具有显著差异性。

6、抓取分析

抓取分析就比较简单了，判断 UA 和 ClientIP 访问占比，抓取一般特征是单个 UA 访问量突增，ClientIP 比较集中，结合 QPM 长期趋势，判断是正常访问还是抓取。

7、程序异常分析概览

为了更好的反映小程序的异常，会收集异常信息进行统计分析，这里和前面类似了，就不展开分析了。

六、道阻且长, 思考从 1 到 n 的演化

做到这，小程序可观测性平台已经从 0 到 1 了，但这只是一个开始，后续要如何演化推进，还面临了很多困难。

1、如何验证？

可观测性平台是否能帮助异常定位呢，线上真实异常可以验证，但太被动了，能否主动模拟异常？如模拟抓取，或单个机器异常。这部分也是今年主要发力的地方，会通过混沌实验平台去辅助故障演练。

2、如何推广？

小程序面向的业务场景茫茫多，如何让工程师转变习惯去适应新的排障工具，也是一个难点。这部分除了培训分享以及持续迭代平台外，可以召集大家攻防演练，在实践中让大家快速掌握新工具，发现平台的不足一起共建。

3、如何横向迁移？

其实这次只是做了小程序端的可观测性，能否延伸到其他各端(触屏/PC/APP)呢？能否推广到中间件，能否推广到其他业务呢？试想一下，业务团队基于 MDD 达成共识后，工程师很多工作就能被量化了，比如优化了几个慢路由，降低了 p99 时延，先于用户发现问题，加速定位问题，是否提升了 UV 等等，都可被观测到。其次工程师可以主动发现一些问题，如上线后接口变慢了，到底慢在了哪里，是否存在慢 SQL 风险等等，就会主动去探寻风险点。

4、如何更快定位异常？

工程问题是需要数学建模，可观测性只是第一步，要想提效不能靠人脑经验分析，如何评估异常的显著差异及关联性，需要选择相应的算法，通过函数拟合建模分析。

5、如何优化用户体验？

数据分析，不同的人会有不同的思路，可观测性反映的现象由于每个人的经验不同，排查思路可能也迥异。另外异常分析定位平台无法穷举所有的异常，就像患者病因溯源一样，很多分析场景具有跳跃性。平台能做的就是尽可能多的给出工程师常用排障按钮，就像超链接一样，让大家按照自己的思路去排查。后续分析这些行为，选择最短路径，固化到程序中，从而达到 AI 智能根因定位。

缩短 MTTR 还有很长的路要走，一起共勉，道阻且长, 行则将至，行而不辍, 未来可期。