随着业务的发展,程序逻辑会变得越来越复杂,为了保证线上系统不出 Bug,我们可能做了很多努力。但是,谁又能保证不出线上 Bug 呢?
唉!世界上最痛苦的是:工作还在,奖金没了。只有尽快解决才能挽救年终奖。然而世界上最遥远的距离就是可以调试的本地和出现 Bug 的线上。那么面对一些系统,既不能打断点调试,Bug 又无法在本地复现,我们该如何解决?
接下来,我们就来讨论一下这一富有挑战性的工作。
假如生产环境有个 Bug
调查线上问题,我们首先会借助于 Log、Tracing 和 Metrics。对于简单的报错,查 Log 就能解决。对于复杂的系统调用和逻辑错误,可能要借助于 Tracing 查看上下文。调查性能问题,查看 Metrics 会更有帮助。
如果通过上述手段就已经定位到了问题,是很幸运的。但有时我们会发现关键的位置缺少了日志,没法准确的获知代码运行情况,这会极大阻碍我们清晰的定位问题。
缺少日志只能补上,再发布一次。对于大多数应用系统来说,发布一次的时间成本是不低的,从数分钟到数小时不等。补日志的过程来上几次,要耗费很多心力,同时也要顶住不小的业务侧的压力。所以生产系统上发现了 Bug,找起来通常很不容易。
有没有更好的方法?
和稍有经验的同事讨论,相信他一定会给你推荐 Arthas。Arthas 相比与远程 Debug,对于环境的依赖更少,也不会因为打断点而阻塞业务请求。但是如果你不是一个运维老炮,那当线上问题发生了,求助于Arthas,你可能会发现短时间内不知从何入手,Artha