本以为线上问题就已经够棘手了, 没曾想, 线上的偶现问题才是最要命的
好些日子没写文章了, 今天不扯代码, 讲点没有多少营养的心得体会
一, 真正难解的问题
作为最接近用户的前端, 每每出现问题当然首当其冲, 如果必现也就罢了, Debug 或者 抓包什么的反正各种手段, 是自己的问题解决问题, 不是自己的问题, 也方便甩锅出去. 但是如果这个项目恰好还复杂度高, 链路长, 关联方很多, 并且这个问题还是 偶现 的 线上 问题, 无异于在开动的火车上排查轨道上出现的大石头, 却还不知道大石头会在哪出现, 你说绝望不绝望
遇到这样的问题该怎么做呢? 当然不是放弃啦
二, 如何应对
尝试寻找复现路径
虽虽然是一个偶现的问题, 如果复现的概率比较高, 尝试在这些复现的现象当中寻找一些内在的关联, 例如 弱网, 快速重复点击, 超时操作等等, 需要一些经验以及运气. 如果有幸找到了必现路径, 那么恭喜啊, 这个问题从一个 偶现 的问题降级到了一个 必现 问题的 Level. 这个时候应该怎么做还需要我教你!!?
分析代码可能的问题, 逆推必现路径
上面第一步, 可以让测试的同学帮忙操作, 而你呢, 可以把精力放在分析你的代码上, 考虑各种场景, 是不是会有漏洞, 是不是会导致问题, 然后再来逆推必现路径. 如果某个逆推出来的路径刚好可以复现这个问题. 那么, 拍完大腿动动手指把问题解决, 你就可以好好去享受你的下午茶了
完善监控日志
糟糕, 除了客户线上反馈了这个问题 (视频截图为证, 抵赖不得), 整个项目组没有谁能复现这个问题, 或者就算测试的同学给偶然复现了, 也根本来不及让你 debug 捕捉日志. 你在分析代码上也发现不了蛛丝马迹, 这个时候就要依赖于日志系统了. 在你觉得必要的地方, 打印日志上传日志系统, 毕竟以线上用户的量级, 就算发生的概率只有千百分之一, 也很容易收集到一些关键的信息
带了日志的版本发出去一段时间之后, 是时候分析日志了, 某个接口报错了? 某个 native 的 js api 没有返回? 还是后天返回的某个数据类型跟预期的不一致? Anyway, 总算可以把锅甩出去了
串联全链路的日志标识
前面说了, 整个系统复杂度高, 链路很长, 如果你收集到的异常日志, 只是没有收到后台的某个消息, 当你理直气壮的去找模块 A 的后台同学的时候, 他查了日志之后白了你一眼, 你看你看, 我消息发出去了啊, 应该是别的模块有问题吧. 然后你再找到模块 B, 模块 C, 得到了相同的答案, 你说你能把锅甩给谁
本文当然不是叫你甩锅的啦, 毕竟谁的问题, 都是这个项目有问题, 作为项目成员, 你要有 owner 意识不是, 不管是什么问题, 都要尝试定位解决
这个时候, 不但需要我们每个模块都有日志, 还需要有一个能够串联全链路的唯一标识. 也就是说, 在设计之初, 前后台以及各个关联方, 要做好这个全链路的日志体系设计. 这样一旦出现问题, 就有迹可循了, 很容易就揪出来有问题的环节
三, 总结
解决偶现问题, 经验至关重要, 这需要慢慢沉淀积累, 没什么好说的. 然后剩下最关键的, 就是完善的日志体系设计了, 这需要整个项目组的努力, 而你需要成为一个推动者
另外, 程序的状态设计合理, 异常路径考虑充分, 也非常有利于预防这类问题的发生, 毕竟, 现在不管是 react 还是 vue, 都已经是面向状态, 数据驱动的编程了
来源: https://juejin.im/post/5ad2ba27f265da2385334d04