电商转化率低？90%用户行为数据被服务器日志埋没了

　　去年十一月那波大促，运维组被拉去给运营部擦屁股——转化率比平时还低三个点，老板在群里@全员骂了半小时。我原以为又是WAF规则没调好，结果翻日志才发现，安全组把用户行为数据全当攻击流量给过滤了。那堆Nginx日志里，有个IP连续三天凌晨两点访问/api/cart/add，每次UA都带点乱码，安全策略直接给它标红——可后来一查，这他妈是测试组新写的爬虫，UA里故意加的混淆字符串，结果被WAF当成了XSS攻击。

　　最离谱的是，运营部要的“用户停留时长”数据，全埋在access.log的响应时间字段里。安全组为了省存储，把日志轮转周期从七天改成三天，结果大促当天的数据全被覆盖了。我蹲在机房翻备份盘，找到个三天前的.gz文件，解压时手都在抖——解出来一看，好家伙，日志里全是404错误，原来那天CDN节点挂了，用户访问失败的数据倒留着，成功的请求全被安全策略截断了。

　　那天晚上十二点，安全组小王在群里发了个截图：某台Web服务器上多了个/tmp/xxx.sh的文件，权限是777。他@我说：“哥，这不会是马吧？”我点开一看，文件内容是空的，修改时间是三天前——正好是日志轮转那天。后来查监控才发现，是测试组用ansible部署脚本时手滑，把临时文件扔到了/tmp下，结果被安全扫描当成可疑文件报了警。小王盯着屏幕叹气：“这要是真马，溯源到一半日志没了，不得被老板骂死？”

文章配图，仅供参考

　　我后来翻了下安全策略的规则库，发现三分之一的规则是“宁可错杀三千”。比如有个规则是拦截所有含“../”的URL，结果把运营部做的“商品分类跳转”功能给拦了；还有个规则是拦截HTTP方法为DELETE的请求，可移动端API确实需要用DELETE删购物车项。安全组说：“这些规则都是去年黑产攻击时加的，改一个得测半个月，谁敢动？”

　　最气的是，运营部要的“用户点击热力图”数据，全在JavaScript的错误日志里。安全组为了防XSS，把所有console.log的输出都禁了，结果前端埋的点数据全没传回来。我蹲在前端组工位旁看他们调试，小李边敲键盘边骂：“这安全策略跟狗皮膏药似的，粘上就撕不下来！”

　　后来我找了台测试机，把安全策略全关掉，让运营部跑了一天的数据。结果发现，转化率低的真正原因是支付页面加载太慢——有个第三方SDK的JS文件卡在CDN上，用户等不及就关了页面。可安全组之前非说这SDK会泄露用户数据，死活不让用，运营部没办法，只能换个慢的。我拿着测试数据去找安全组老张，他叼着烟说：“安全是成本不是收入，你们运营要数据，自己平衡风险去。”

　　现在想想，那波大促的问题根本不在技术，而在屁股。安全组怕出事，所以把所有可能的风险都拦了；运营组要数据，所以把所有可能的流量都放了。结果就是，用户行为数据被安全日志埋了，安全策略把正常业务拦了，最后老板骂的是运维组——因为我们“没保障好系统稳定性”。

　　昨天下班前，我在服务器上看到个陌生文件叫/var/log/security_audit.log，点开一看，是安全组新写的审计脚本生成的。文件里全是“用户XXX访问了禁止URL”的记录，可运营部要的“用户XXX把商品A加入了购物车”的数据，一条都没有。我合上电脑，心想：这他妈才是真正的“安全是成本不是收入”——成本是运维组的头发，收入是老板的骂声。

　　下一步我打算找运营部和安全组开个会，让他们自己吵出个结果——反正我是不想再当夹心饼干了。不过说实话，我挺好奇他们能吵出什么花样——毕竟安全组手里有WAF，运营组手里有KPI，这两边掐起来，可比看日志有意思多了。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!