排查线上问题的9种方式

德国科技管理专家斯坦门茨早年移居美国，他以非凡的才能成为美国企业界的佼佼者。一次，美国著名的福特公司的一组电机发生故障，在束手无策之时，公司请斯坦门茨出马解决问题。

斯坦门茨在电机旁仔细观察，经过计算，用粉笔在电机外壳划了一条线，说：“从这里打开，把里面的线圈减少16圈。”工人们照他说的一试，电机果然运转如初，福特公司给他酬金时，他索价一万美元。

公司老板觉得一条线要一万美元未免漫天要价。斯坦门茨回答：“用粉笔划一条线一美元，而知道在哪里划要9999美元。”公司老板认为言之有理，乃照付一万美元。

这个励志故事告诉咱们要懂得如何排查问题的重要价值。今天咱们就来总结一下排查问题的9种方法：

基础方法

监控告警

问题发生常用的手段有生产测试、监控告警和人工客诉。人工客诉是咱们最不愿意看到的，那就需要在产生业务影响前及早发现。监控告警是发现问题的有效手段，具体可以参考《通知&告警治理(降噪)的7种方法》这篇文章。

日志埋点

埋点是了解用户行为的重要步骤，但更重要的目的是识别用户的关键路径。注入特定的代码以记录关键指标是提升应用性能的重要步骤。

日志和埋点之间存在着细微的差别。埋点可以看作是日志的子集。被埋点的任何数据都应该记录在日志中。

埋点承担了为聚合分析发布关键性能数据的职责，日志则提供了用户在不同级别跟踪应用的细节信息，从低到高依次为:

 ● Verbose:几乎提供了所有的细节，主要用于跟踪执行过程中控制流
 ● Debug:表示数据主要用于调试
 ● Info:表示非错误信息
 ● Warning:表示可恢复的错误
 ● Error：表示不可恢复的错误

日志的记录会贯穿应用的整个生命周期，而埋点只应该用在开发的特定阶段。通过埋点，可以把特定类型或有有价值的信息素材收集起来，基于这些素材可以做非常多的有价值的分析、追踪。

问题复现

这个不用多解释，聊聊复现的步骤：

● 确保所有的步骤都被记录。记录下所做的每一件事、每一个步骤、每一个停顿。无意间丢失一个步骤或者增加一个多余步骤，可能导致无法再现软件缺陷。在尝试运行测试用例时，可以利用录制工具确切地记录执行步骤。所有的目标是确保导致软件缺陷所需的全部细节是可见的。

● 特定条件和时间。软件缺陷仅在特定时刻出现吗？软件缺陷在特定条件下产生吗？产生软件缺陷是网络忙吗？在较差和较好的硬件设备上运行测试用例会有不同的结果吗？

● 压力和负荷、内存和数据溢出相关的边界条件。执行某个测试能导致产生缺陷的数据被覆盖，而只有在试图使用脏数据时才会再现。在重启 BUG 复现方法总结机器后，软件缺陷消失，当执行其他测试之后又出现这类软件缺陷，需要注意某些软件缺陷可能是在无意中产生的。

● 考虑资源依赖性包括内存、网络和硬件共享的相互作用等。软件缺陷是否仅在运行其他软件并与其他硬件通信的“繁忙”系统上出现？软件缺陷可能最终证实跟硬件资源、网络资源有相互的作用，审视这些影响有利于分离和再现软件缺陷。

● 不能忽视硬件。与软件不同，硬件Hi按预定方式工作。板卡松动、内存条损坏或者CPU过热都可能导致像是软件缺陷的失败。设法在不同硬件不再现软件缺陷。在执行配置或者兼容性测试时特别重要。判定软件缺陷是在一个系统上还是在多个系统上产生。

抓包分析

tcpdump命令配合Wiresshark等解析工具可对网络问题做初步的排查。比如http请求是明文传输，可以抓到完整的请求内容。但是如果是加密的，至少可以看到有没有RST等异常。或者原本应该观察的到返回包有没有，判断是哪个链路出的问题。

这需要对网络知识有比较深的了解。可通过《网络通信知识地图》进行学习，特别是《白话TCP/IP原理》要了解。

高危方法

linux命令

有点命令危险性不高，比如TOP，使用方法可参考：《时刻掌握系统运行状态-深度理解top命令》。但是在线上不能随便用。比如程序正在写一个文件，这时候用命令行执行vim，可能导致fd文件描述符失效。关于文件描述符可参考《白话linux操作系统原理》或《趣谈IO多路复用的本质》。

感兴趣的朋友甚至可以自己实现一下fd文件描述符失效：

第一步：进程打开日志文件,使用lsof -p pid

第二步：vim没打开文件前(或者打开vim没进行wq保存)

第三步：当vim 修改文件后wq时,会提示

提示文件在读期间被修改了,我们选择yes

第四步：此时再使用lsof -p pid命令来查看打开的文件描述符，进程打开的文件描述符的状态变为了deleted状态。

linux命令可以作为排查问题的利器，比如我在《懂得三境界-使用dubbo时请求超过问题》里提到的netstat -s ，但是要注意不要对线上造成影响。

下面用图来总结常用命令使用场景，图小需要手工放大看：

留后门法

很久之前我们使用Redis，但是管理端做的不太好，我就在程序里留了后门：可以通过http接口对Redis的进行增删改查操作。但是用http接口做管理，意味着没有标准的权限控制和操作标准流程，很容易受到攻击或者误操作。

更正统的方法是用标准的运维工具代替这些后门。

线上调试

举个例子，有次我们在进行测试环境演练，出现了个怪异的问题。后来有同事说其他一个同事也在用这个环境做调试，所以才会调用哪个接口的地方卡住，出现问题。这种问题要是出现在线上，就是故障了。

高级方法

代码走查

排查问题的最高境界是只通过review代码来发现问题

逻辑推理

但很多大神的解决步骤是：第一，听别人讲述问题现象；第二，提出问题以求证；第三，推理出大致原因并给出可选方案及方案的注意点；第四，自己、更多情况下是他人进行验证。为啥是他人，能达到这种境界多是领导或者帮别人排查问题的救火队长，问题发生和自己并没有直接关系。

想达到这种境界还是需要平时的积累和深入理解和深耕。源码和网络知识学起来~~

总结

一张图总结今天介绍的方法:

文章转载自公众号：编程一生