关于业务敏感度

恰巧，结合最近发生的一个项目现网问题，自己还是太嫩的点。

博文提到，碰到问题，应当解决根源问题而不是表象问题，但最近发生的情况呢，我其实也跑偏了。

过往背景

2022年1月下旬，某个驻地反馈说后台的数据当日的不展示了，那个数据是每天定时从SLS查询汇总入库后供用户查看的。既然不展示了，那必然是解析的部分出了问题，查看解析日志，发现是查询超时了。恩~~~当时的思路了，阿里云这SLS不行啊，之前好好的，最近怎么超时了呢？超时了怎么办？加大等待时间呗~

于是跟进到库源码，直接把原始的50秒超时改成了300秒，至此，问题解决……当时这事儿就这么过去了。

到了今年8月下旬，问题再次发生~恩？？？难道是代码没有升级上去？不可能，现网版本早高于1月份的版本了，不信邪，核对了实际代码，也确实是改过的。

那为啥还会查询超时，阿里云SLS太菜了吧（注意，到这里，我依然盲目自信觉得是阿里云的问题）。那继续加大查询超时时间也不合适啊，都300秒，5分钟了哎~

不行，问题肯定没这么简单。这个时候，浩哥说去看看SLS的数据吧，一看发现，数据量还真不少，应该是后面逐步把各类日志都汇总到了一个日志主题所致。

玩儿数据库的也都知道，你一个查询最初很快，但如果是一条不合理的查询，随着数据量的递增，可能会越来越慢。于是问题回到，SLS查询汇总的query上是不是有问题。

回头看代码：request_method:GET，哦擦，竟然是直接遍历了所有GET请求做汇总……这能快起来？

那么改进思路呢？汇总的url其实是有明确关键字的，于是浩哥给出了方案：request_uri:click。

只汇总url包含click的部分，这样，一下子查询时间就下降了两个量级……

问题到这里，才算打到了七寸，真正的得到了解决。

问题是个小问题，但我对待问题的态度，和新人并无区别，那毫无意义的高傲让我忽略了分析问题的本质。这个优化其实早就应该由我自己发现并进行的，但是，基本的业务敏感度变钝了，直到问题二次发生才在浩哥的帮助下从根本上解决掉。

自信和骄傲是特性，但过分的自信和骄傲就是缺陷了。面对问题，要保持业务敏感度，努力探索问题背后的原因，我是菜鸡我要谦卑。

对不起，这回是我错怪阿里云了😂~

如您从本文得到了有价值的信息或帮助，请考虑扫描文末二维码捐赠和鼓励。

如本文对您有用，捐赠和留言 将是对我最好的支持~（捐赠可转为站内积分）
如愿意，请向朋友推荐本站，谢谢。

尊重他人劳动成果。转载请务必附上原文链接，我将感激不尽。