如何应对线上的偶现问题

4,303 阅读4分钟

本以为线上问题就已经够棘手了,没曾想,线上的偶现问题才是最要命的

好些日子没写文章了,今天不扯代码,讲点没有多少营养的心得体会

一、真正难解的问题

作为最接近用户的前端,每每出现问题当然首当其冲,如果必现也就罢了,Debug 或者 抓包什么的反正各种手段,是自己的问题解决问题,不是自己的问题,也方便甩锅出去。但是如果这个项目恰好还复杂度高、链路长、关联方很多,并且这个问题还是 偶现线上 问题,无异于在开动的火车上排查轨道上出现的大石头,却还不知道大石头会在哪出现,你说绝望不绝望

遇到这样的问题该怎么做呢?当然不是放弃啦

二、如何应对

尝试寻找复现路径

虽虽然是一个偶现的问题,如果复现的概率比较高,尝试在这些复现的现象当中寻找一些内在的关联,例如 弱网、快速重复点击、超时操作等等,需要一些经验以及运气。如果有幸找到了必现路径,那么恭喜啊,这个问题从一个 偶现 的问题降级到了一个 必现 问题的 Level。这个时候应该怎么做还需要我教你!!?

分析代码可能的问题,逆推必现路径

上面第一步,可以让测试的同学帮忙操作,而你呢,可以把精力放在分析你的代码上,考虑各种场景,是不是会有漏洞,是不是会导致问题,然后再来逆推必现路径。如果某个逆推出来的路径刚好可以复现这个问题。那么,拍完大腿动动手指把问题解决,你就可以好好去享受你的下午茶了

完善监控日志

糟糕,除了客户线上反馈了这个问题(视频截图为证,抵赖不得),整个项目组没有谁能复现这个问题,或者就算测试的同学给偶然复现了,也根本来不及让你 debug 捕捉日志。你在分析代码上也发现不了蛛丝马迹,这个时候就要依赖于日志系统了。在你觉得必要的地方,打印日志上传日志系统,毕竟以线上用户的量级,就算发生的概率只有千百分之一,也很容易收集到一些关键的信息

带了日志的版本发出去一段时间之后,是时候分析日志了,某个接口报错了?某个 native 的 js api 没有返回?还是后天返回的某个数据类型跟预期的不一致?Anyway,总算可以把锅甩出去了

串联全链路的日志标识

前面说了,整个系统复杂度高,链路很长,如果你收集到的异常日志,只是没有收到后台的某个消息,当你理直气壮的去找模块A的后台同学的时候,他查了日志之后白了你一眼,你看你看,我消息发出去了啊,应该是别的模块有问题吧。然后你再找到模块B、模块C,得到了相同的答案,你说你能把锅甩给谁

本文当然不是叫你甩锅的啦,毕竟谁的问题,都是这个项目有问题,作为项目成员,你要有 owner 意识不是,不管是什么问题,都要尝试定位解决

这个时候,不但需要我们每个模块都有日志,还需要有一个能够串联全链路的唯一标识。也就是说,在设计之初,前后台以及各个关联方,要做好这个全链路的日志体系设计。这样一旦出现问题,就有迹可循了,很容易就揪出来有问题的环节

三、总结

解决偶现问题,经验至关重要,这需要慢慢沉淀积累,没什么好说的。然后剩下最关键的,就是完善的日志体系设计了,这需要整个项目组的努力,而你需要成为一个推动者

另外,程序的状态设计合理,异常路径考虑充分,也非常有利于预防这类问题的发生,毕竟,现在不管是 react 还是 vue,都已经是面向状态、数据驱动的编程了