稳定性建设之如何快速定位线上问题

背景

当发生很明显的线上问题时，我们可能直接就回滚代码了。但多数线上js error或告警 反映的只是一些边缘的case，量很小，但也是安全隐患，需要定位和排查。但由于量很小，或者触发的情况很特别，导致排查的难度大，效率低下，影响其他工作进度。所以花点时间，总结思考一下，如何提升排查疑难问题的效率

快速定位线上问题的办法

其实就2点：

1. 看报错信息 + sourcemap，定位代码问题
2. 找到真实用户访问链路，复现错误，再解决

展开讲一讲

1. 看报错信息 + sourcemap，定位代码问题

贴一段报错信息

TypeError: `undefined is not an object (evaluating 'n.headers')`
- webpack:///node_modules/vue-loader/lib/index.js

• 很明显是代码没有兼容好

贴一段对应sourcemap

• 找到对应代码位置，处理一下就行了

基本上一些明显的错误，直接看这些就够。

但有些情况是，报错信息很明显，但这个代码可能以前没出过问题，只是最近才开始出问题（很常见），通过查看一些最近的提交记录也很难归因，并且只是少量的用户会这样。特别是一些网站是动态生成的，有多少页面是不固定的

这种时候就需要定位真正的用户访问链路

2. 找到真实用户访问链路，复现错误，再解决

我们要模拟用户情况的话，需要充分了解用户当时的情况，所以我们需要这些信息：

1. 了解用户使用环境：浏览器种类和版本、设备型号

   • 可能是浏览器版本 或 mobile端 或 操作系统 兼容问题

2. 了解用户使用场景：具体哪个url，url上有哪些参数，并了解url链路（中间跳了几次）

   • 知道具体url + 参数 + url链路，才方便我们复现问题

3. 了解用户操作链路：包括前端 + 后端

   • 比如先点的哪个按钮，跳到了哪个页面，然后才报错的，这样可以缩小排查问题的范围

   • 当请求到了后端时，后端很可能也有多个下游链路，并且操作步骤也很多（有日志），如果可以整个串起来，那么排查问题就会变得很轻松（相当于知道了代码执行到那一行出错的）

4. 了解复现概率，比如10000个用户访问，80次出错，错误率0.8%

   • 这种偶现的问题，我们可能很难复现。所以需要整合上面提到的信息，来帮助我们复现。 另外了解错误量级，可以协调资源 更快速的修复问题

   • 如果一直复现不了，可以尝试用弱网试试

Q&A（题外话）

Q：如何拿到真实用户的js error？

• A：公司如果没有这个基建的话，那么恭喜你，机会来了：你可以实现一套（结合开源sentry），然后推广到全公司用

Q：如何拿到真实用户的sourcemap？

• A：线上包肯定是没有sourcemap代码的，否则十分影响性能。所以只能通过上面收集到的js error，来用sourcemap包反解。 具体实现思路是：实现一个webpack plugin（假设你用webpack），作用：让项目在打包阶段，把sourcemap打包出来，然后上传到你们的服务器，完事后删除代码包里的sourcemap。然后下次捕获到线上js error时，用这个sourcemap反解出来

Q：如何拿到用户前端操作链路？

• A：基建应该要支持这个。如果公司基建不支持的话，建议去提需求，实在不行就自己去打路径埋点。比如：页面show -> click/input/其他行为 -> 其他。然后可能还需要自己搭看板，把这些埋点串起来（用session）

Q：如何拿到后端操作链路？

• A：思路和上面一样，需要一个session id，把整条链路串起来。比如:从 SSR服务 -> 服务A -> 服务C -> 服务B，大家都用同一个session id打log，最终可以通过这个session id把整条链路的log给串起来！

如果是端上项目，还有webview环境的话，也是这个 session id把整条链路串起来的 思路

---

码字不易，点赞鼓励！！