走近科学:排查业务错误的“暗物质”成分
虽然我们有完善的数据埋点和错误日志收集,但是有时候用户报告的问题有可能正好没有被埋点和日志覆盖,这不仅给我们解决问题造成困难,也无法估计问题影响范围,本文结合实例和时事要闻对此类问题的解决和估算做了分析和展望。[原文链接][原文链接]
什么是业务错误的”暗物质“成分?
我们判断业务的错误率一般是通过埋点,遇到异常或者失败的时候上报一个错误状态以及错误信息,这样可以监控到业务的失败率。应该说,绝大部分业务错误通过这种方式是可以检测到的。埋点就像警戒雷达一样随时监控错误,一旦发生就告警通知我们修复。
但是难免会出现意外的情况,业务发生了错误但是并没有上报埋点。这样的错误就像暗物质一样,它只对用户发生作用,不和我们的埋点、日志发生作用:悄悄得给用户制造一场意外,默默得退回到一个未知角落,静静得等待时机下一次作妖,我们的警戒雷达却无法发现它。因为这种“暗物质错误”不会报告埋点,我们也不能通过埋点知道它是否发生,不掌握它发生了多少次,只能依靠少数热心用户主动报告,这些热心用户很珍贵,他们就是我们的眼睛。
下图是一位特斯拉热心用户在主动报告问题:
物理上的暗物质,是和引力场发生作用,但是不和电磁场发生作用的物质,因为人类观察宇宙的主要手段就是电磁波,所以被叫做暗物质。和这类不反应在埋点上但是反应在用户体验上的错误就很像。
“暗物质错误”的危害
特斯拉目前遇到的问题,疑似是这种错误:用户反馈了错误,但是他们排查埋点没有发现问题点,也不能用自己的设备重现问题,于是公布了错误发生前半小时埋点发动大家一起查:
就我遇到的情况,有三种原因:有的是因为吞掉异常导致,当然就无法检测到错误现象(被我们吞了);有可能是第三方SDK导致,比如第三方SDK本来失败了, 但是返回“成功”给快手,这样自然也会制造一个无法被检测到的错误;也有可能是手机系统问题,虽然比较罕见,但是也不是不可能,我们最近遇到的一个问题就是vivo Android 11手机上出现的,因为是系统问题,应用层面基本没机会捕获到这样的错误。当然不排除其他原因,好比特斯拉遇到的应该就不是这三种之一。
收到用户上报以后,如果能及时定位和解决问题就还好,然而这类问题也只有上述的第一种情况还可能相对容易及时定位,另外两种情况都需要和第三方反复沟通,甚至需要拿到问题现场获取日志,这个时候除了解决Bug的超期压力以外,我们还面临着另外一个压力就是,我们不知道这种错误在每天好几亿用户里面占比多少,无法评估这类错误的严重程度。
想一下,如果你的手机偶尔重启,你会联系厂商报告错误吗?大概心中暗下决心:换手机也换牌子!
很久以前我收到过一个用户反馈分享错误,还好这个错误通过查埋点可以查到失败信息和函数调用堆栈,它仍然在监控中只是没有设置在报警范围里面而已。这个用户报告的错误是每天发生N次,已经持续两星期,也就是说一个主动上报用户背后,可能是14*N次错误(pv),具体数字恕我保密了。这样可以在埋点查到的错误,总是有办法处理的,后来我们调整了APM监控,增加了集中出现的错误的监控,把这类问题纳入了警戒雷达的视线。
从这个角度来说,“暗物质错误”的最大危害就是我们不知道它有多严重。
就像物理学的暗物质可以通过电磁波以外的手段探知一鳞半爪,这样的“暗物质错误”也有可能通过埋点数据分析,至少能做到管中窥豹。
捕获已知“暗物质错误”的具体案例
就我遇到的一个案例来说,用户反馈了错误,虽然不能用埋点直接排查出来,但是根据现有的埋点也是有可能估计出大致的数量的。
问题的具体现象是用户执行QQ或者QZone分享的时候,没有拉起QQ,反而提示了”邀请成功”。
我们通过添加日志给用户重现回捞以后确认是QQ SDK的问题,没有成功拉起QQ并且直接返回了取消回调。在埋点的表现上看,这种错误隐藏在了普通的取消事件里面。
这个问题在排查过程中联系了QQ的技术支持人员,但是由于用户那里的QQ日志回捞失败,导致无法进一步推进。我们观察QQ和QZone的相关分享数据,在用户报告前后没有发生可信的数据波动,可以排除这个问题是刚刚发生并且有较大影响的可能,但是有没有可能这个问题从一开始就存在呢?它占比是多少呢?
更为严峻的是,这个用户提到,他的很多朋友也有一样的问题。
从正面的分析是不可能得到答案的,出错的取消和正常的取消对我们来说都是来自QQ SDK的取消回调,不会标记出来“这个取消是错的,请关注”,“这个取消是用户的,不用关注”。
不过我们可以观察一下龌龊的金条有什么特征:它是QQ SDK直接返回的,用户没有做任何操作,界面闪了一下就消失了。
那么,这样的取消,速度应该很快,比普通的用户亲手点取消按钮的取消分享要快很多。而且我们添加日志也证明这一点,用户那里上报的埋点可以计算出来从启动分享到取消只有2.15秒。
正好我们的埋点记录了开始分享、结束分享的时间,通过计算时间,如果大部分用户的取消用时间都比较长,那么就可以放心的认为这个错误影响并不大。
按照这个思路,我下载了一天当中两个小时的分享数据,然后写脚本计算了这些数据当中低于2秒的取消,占比在10%左右,考虑到手比较快取消掉的因素,又检查低于0.5秒的取消,占比不超过5%,那么可以判断出这个错误影响并不严重。
也可以用SQL直接查询,这样可以针对一整天采样,效率更高。
不过我们还遇到另外一个案例就不能这样简单的解决,这个问题是vivo 的Android 11手机上可能出现分享面板没有绘制出来,但是仍然保留了交互能力,对于这样的问题就比较复杂,可能可以通过检测被误点的按钮来排查,不过还没有尝试。
主动探索未知的“暗物质错误”
当用户反馈以后,我们就知道了某种“暗物质错误”的表现形式,按图索骥的去查出一个估计的错误数量级,能够评估错误严重程度,或者尝试与疑似用户联系取得更多的错误样本帮助解决问题,固然比收到反馈无可奈何好得多。但是有没有可能主动出击,在用户反馈以前就知道可能存在问题,通过增加日志、主动联系可能出问题用户方式解决问题呢?
简单一点的办法是找出“不合理的埋点”。好比分享埋点,如果从启动到结束的时间特别短,短得低于常识,不管成功、失败还是取消,都是很可疑的现象,值得增加日志去排查。虽然埋点上报了,但是它不合理,那么这很大概率是一个“暗物质错误”在作妖。
还有一个比较大胆的想法,我们的用户数据足够多,不知道能不能引入大数据分析,判断出来偏离主流用户的一些行为,如果偏离超过2个标准差一般就认为很异常了。类似前面的第二个案例,它没有简单的判断方法,但是因为用户看不到界面,却可以交互,就会发生乱点按钮的现象,如果可以通过一定方式判断“乱点按钮”,对我们已知的vivo Android 11用户群体重点排查,也许可以估计出来问题影响范围。我做客户端开发,对大数据分析是外行,希望专家们看一点是否有可能?
不过坦率讲,这样做可能投入产出比不高。
“暗物质错误”的总量估计
科学家估计宇宙中的暗物质占比大约是26.8%,我们有没有可能估计一下这种“暗物质错误”的占比呢?
具体的数值很难给出,但是好消息在于这类错误肯定概率很低,毕竟我们的发布流程是必须经过严格的测试才会上线,能够从我们的测试工程师手里逃过bug的,本身出现的概率就已经很低了,应该介于线上问题的数量和被发现的线上问题数量之间,所以是个很低的比例。
也因此这类“暗物质错误”的捕获绝不是件容易的事情,如果容易,我们的测试工程师就不会放过它。数据工程师需要精心设计埋点得以互相验证,开发工程师也需要认真核对和维护埋点,一般刚刚添加的埋点是正确的,就怕代码重构或者修改附带修改埋点导致错误。做到这些,出现了此类问题的时候,我们就可能通过埋点之间的不合理现象捉出来这些“暗物质错误”。
标签集合/Tag clouds
C++
Symbain
轻松汇编
算法
论文学习
资治通鉴
Delphi
编程之美
Poco
MFC
Linux
IFC
知乎
汇编
数据分析
交叉编译
poco
j2me
android
XML
Java
DTD
飞信
零宽断言
诺基亚
联系人
编程
真值表
池西木
正则表达式
多线程
命令行
优化
stream
configure
cmake
VIM
UiAutomator
TDD
Symbian
Sqlite
SourceInsight
Python
MPAndroidChart
Kotlin
Flutter
Dokka
Chatgpt