走完线上 BUG 定位最后一公里
作者 | 陈陈
来源 | 阿里巴巴中间件
一个小故事
周末12点的闹钟在回龙观均价3000的出租屋急促的响起，程序员小A慵懒的拿过手机，滑开手机通知栏，没有未接电话，点开手机的拦截信箱，没有报警短信，昨晚的发布一定很顺利。小A幸福的伸了个懒腰。戴上3000块的BeatsSolo Pro，音乐逐渐响起来，小A缓缓的闭上了眼睛，正午的阳光从窗户漫进来，撒在小A稀疏的头发上。此时的小A正在脑海中勾勒着自己美好的未来。房东说：十年前住在这间屋的小B，现在已经是某度的T10 大佬，五年前住在这儿的小T，现在已经在某条带领200人的团队，想到这儿，小A的嘴角微微上扬，那我也一定不会太差吧～
嘀嘀..耳机里传来两声消息提示音，小A心里咯噔一声，刺骨的寒意弥漫开来，北京三月的阳光突然就不暖了。小A用力的微微睁开双眼，通知栏测试同学小C的头像一闪而过。
xx线上BUG紧急修复群
小C: “@小A 昨晚上线的代码好像有点有问题，来公司看下？我在公司等你。”
点开群设置，老板的头像赫然在列。
怀着愧疚、徘徊、悔恨、无奈、愤怒的心情，小A翻身穿上他在路边买的价值20元的人字拖，坐上了前往西二旗的地铁十号线。
不久，西二旗某办公室传来了亘古不变的对话，“这段代码测试过，在我电脑上没问题啊”、"你重启下试试"、“是不是代码没上线”、“是不是谁把我代码冲掉了”、“你们测试数据是不是有问题呀”……于是一个下午过去了、一个晚上过去了、一个周末过去了、一个程序员的青春过去了、一个程序员本就不长的职业生涯过去了。
一个小总结
上面这个虚构的小故事只是想说明一个简单的现象，程序员的很多时间被线上bug fix占据。因为线上线下环境不一致、输入输出不一等等原因，很多bug定位起来效率低下，耗时巨长，导致很多时候程序员遇到线上bug总是头疼不已，不由自主的想要甩锅给外在因素，在确定是自己的问题的时候再排查问题。那么线上问题排查到底难在哪儿？首先来看看我们排查线上问题的一个基本步骤，这个步骤一般是排查大多数线上问题的步骤。
步骤1：找到能复现问题的输入；
步骤2：判断该输入能否在日常环境构造, 如果能，调到步骤5。如果不能，继续步骤3；
步骤3：查看线上环境日志，看能否找到异常输入相关的异常日志，辅助排查问题；
步骤4：初步推断问题原因，尝试修复并加上更多日志输出。然后打包、发布。重复步骤3直到定位根因；
步骤5：日常构造相同输入，单点调试，定位问题；
实际的场景中，因为线上线下环境隔离的问题，线上的输入很多时候难以在日常环境中构造，大多数时候我们都在步骤2、3、4中循环，于是时间就在循环中慢慢的流逝了。
上面做这么多步骤其实对于查问题而言就是希望可以知道当某段代码执行不符合预期的时候，这段代码的输入是什么，输出是什么，抛出了什么异常，以及代码中每一行的具体执行情况。那么是否有一款产品可以让用户方便快捷的实现这个目标呢？答案是有的。
聊一聊 ARMS
阿里云的应用实时监控服务ARMS是一款应用性能管理（APM）产品，包含应用监控、Prometheus监控和前端监控三大子产品，涵盖分布式应用、容器环境、浏览器、小程序、APP 等领域的性能管理，能帮助用户实现全栈式性能监控和端到端全链路追踪诊断。
ARMS最新推出了Arthas诊断功能，其第一个版本主要包含四个能力，分别是JVM概览、线程耗时分析、方法执行分析以及性能分析：
JVM概览：查看实时的JVM内存、GC信息以及操作系统信息、环境变量、系统变量等信息。
线程耗时分析：查看实时的线程耗时情况，并可查看每个线程实时的方法堆栈。
方法执行分析：实时的抓取满足指定条件的方法执行明细、出入参数以及异常。
性能分析：快捷的通过火焰图的的形式，展示系统性能瓶颈。
聊一聊 ARMS Arthas 诊断
方法执行不符合预期：包括方法执行耗时、方法返回值、方法抛出了异常等情况，表现在应用上可能是一些接口或者服务的RT增高，错误率增高，返回值异常等。
进程CPU耗时突增：一般有代码死循环问题、FullGC导 GC线程耗时高、并发使用HashMap等。
性能优化问题：主要用于分析性能瓶颈，辅助性能优化，包括 CPU 耗时、内存分配、锁竞争、itimer 等情况的性能分析。
其他问题：比如初始化环境变量读取错误、内核版本不符合要求、类冲突等问题。