我在神策做研发 | 与客户难题“对抗”的百余天

 

 

对于每一个客户的问题，不管大小，都需要跟进追踪到底，以获得最佳的答案。

一个问题一个坑，留了坑，前路必将荆棘丛生；填了坑，前路即是坦途。这是神策人的做事态度和行事准则，也帮助我树立了积极的人生观。

如果同行也正在经受类似问题的困扰，希望同行可以通过这篇文章，在排查过程中能够获得一点启发。

刷量？客户反馈异常 IP 发送大量重复数据

从今年 2 月份起，我陆续收到客户反馈：Web JS SDK 短时间内上报了大量重复的数据到神策分析，从而影响了客户的分析、决策和制定运营计划。对于这种情况我们通常称之为 “刷量”。什么是刷量？

图 1  刷量表现—按天

图 2  刷量表现—按分钟

用户所反馈的现象和刷量一致，有几个异常 IP 短时间内密集发送 Web 端重复数据入库。一个 IP 一天发送的重复数据甚至达到了几十万、上百万条，这显然不是一个正常用户产生的行为数据。

我们查看了刷量时的用户行为序列，如下图，可以看到事件是重复循环触发的，时间间隔在几十毫秒。

图 3  刷量发生时的用户行为序列

针对此问题的反馈，我们进行了快速排查及提供初步解决方案。

当时的排查思路：

一，会不会是客户代码 bug 导致重复触发事件？

通过协调运维帮忙查询事件日志，证明这些重复事件的 _track_id（Web JS SDK 对发送数据生成的随机数，每条采集和发送的数据都会有自己独特的 _track_id） 是一样的。从这个方面看，基本排除了是客户代码 bug 导致的，因为即使是代码重复触发的事件，_track_id 是不会重复的。

二，会不会是别人恶意获取了神策的数据采集请求和数据体，使用工具或者脚本伪造请求，灌注脏数据到神策分析服务器？

Web JS SDK 采集的数据，默认使用 image 方式发送数据，GET 请求的数据接收地址和数据体都包含在请求的 URL 中，如图所示：

图 4  Web JS SDK 的数据发送

只要复制该 Request URL 直接在浏览器地址栏访问，或者使用脚本访问，就会有一条一模一样的数据入库。这也符合  _track_id 重复的情况，而且可以集中产生大量的请求，实现灌注脏数据。在本地使用脚本模拟，也能够复现出来数据刷量的情况。

因此，推测的结论是：有人从集成了 Web JS SDK 的页面上，截取了发送的数据请求，并通过脚本灌注脏数据进入神策分析。

根据这一结论，给客户的方案是：将 Web JS SDK 的数据发送方式从 image 改成 ajax，这样请求就会从 GET 变成 POST，在一定程度上避免将整个请求暴露在 URL 上；将出现过