如何优雅地解决线上问题？（完结）

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

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

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

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

系统级别 bug

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

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

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

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

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

perf 工具

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

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

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

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

ps 命令

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

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

大部分情况下通过系统告警就可以知道大...

真诚点赞诚不我欺