title: 程序员如何优雅地解决线上问题？ shortTitle: 程序员如何优雅地解决线上问题？ author: fancy category:

身为一个程序员，遇到线上问题那都是家常便饭的事儿。

如果你在深夜看到一群同事围在一起，他们是在共同探讨什么哲学问题么？非也，他们一定是遇到了线上BUG。

线上问题只要影响到了核心业务流程那便是事故，所以一旦事故发生，无论你在约会，还是周末打游戏，甚至是在睡觉，只要接到了来自公司的电话，那只能赶紧连上公司网络加班了。

BUG分类

线上问题是复杂多变的，我们一般将bug分为系统级别和业务级别bug。

系统级别bug

业务部署在整套系统上运行，一旦出现系统级别bug则业务会被严重拖垮。如CPU爆满、服务不可用、甚至服务器宕机等都属于系统级别的bug。

如果是CPU100%，那是由哪个线程，哪个类，甚至是哪个方法导致的？

若是业务流程正常但是部分服务性能拉跨，那么如何快速定位到问题在哪儿？

因为是线上发生的事儿，所以重点在于如何迅速解决。

以下分享我最常用的一些问题排查工具。

perf工具

perf是linux的性能分析工具，核心作用之一就是用来查看热点函数的分布情况。

用它可以生成火焰图查看到函数的资源占用情况，函数的调用栈越深火焰就越高。所以对于异常的函数一眼就能看出。

如上图通过调用栈你可以看出Monitor管程在反复调用enter和wait，这种情况下就可以判断出该程序已经发生死锁且存在性能问题。假设有大量线程请求这段代码，那么CPU资源将被迅速打满！

在著名的“713B站事故”里技术团队在事故发生时就用到了当前工具生成了火焰图，快速地分析出了事故的根因也就是导致CPU100%的lua热点函数。

ps命令

我们项目部署的服务器里在跑的进程老多了，java进程、nginx进程、redis、消息队列进程等等。

举个例子，假设在某一流量高峰期系统监控到整个服务性能下降5倍，业务被严重拖垮，在确定没有业务层面bug的情况下大概率就是因为服务性能达到瓶颈了。如何确定瓶颈在哪儿？

大部分情况下通过系统告警就可以知道大概问题所在。如发生消息堆积我们就该怀疑消息生产者和消费者的状态，这个时候就要具体去查看消息队列这一进程。

可以使用一些轻量级的linux命令，如ps：

[root@linuxfancy ~]# ps -ef | grep queuejob