德国科技管理专家斯坦门茨早年移居美国,他以非凡的才能成为美国企业界的佼佼者。一次,美国著名的福特公司的一组电机发生故障,在束手无策之时,公司请斯坦门茨出马解决问题。
斯坦门茨在电机旁仔细观察,经过计算,用粉笔在电机外壳划了一条线,说:“从这里打开,把里面的线圈减少16圈。”工人们照他说的一试,电机果然运转如初,福特公司给他酬金时,他索价一万美元。
公司老板觉得一条线要一万美元未免漫天要价。斯坦门茨回答:“用粉笔划一条线一美元,而知道在哪里划要9999美元。”公司老板认为言之有理,乃照付一万美元。
这个励志故事告诉咱们要懂得如何排查问题的重要价值。今天咱们就来总结一下排查问题的9种方法:
基础方法
监控告警
问题发生常用的手段有生产测试、监控告警和人工客诉。人工客诉是咱们最不愿意看到的,那就需要在产生业务影响前及早发现。监控告警是发现问题的有效手段,具体可以参考《通知&告警治理(降噪)的7种方法》这篇文章。
日志埋点
埋点是了解用户行为的重要步骤,但更重要的目的是识别用户的关键路径。注入特定的代码以记录关键指标是提升应用性能的重要步骤。
日志和埋点之间存在着细微的差别。埋点可以看作是日志的子集。被埋点的任何数据都应该记录在日志中。
埋点承担了为聚合分析发布关键性能数据的职责,日志则提供了用户在不同级别跟踪应用的细节信息,从低到高依次为:
日志的记录会贯穿应用的整个生命周期,而埋点只应该用在开发的特定阶段。通过埋点,可以把特定类型或有有价值的信息素材收集起来,基于这些素材可以做非常多的有价值的分析、追踪。
问题复现
这个不用多解释,聊聊复现的步骤:
● 确保所有的步骤都被记录。记录下所做的每一件事、每一个步骤、每一个停顿。无意间丢失一个步骤或者增加一个多余步骤,可能导致无法再现软件缺陷。在尝试运行测试用例时,可以利用录制工具确切地记录执行步骤。所有的目标是确保导致软件缺陷所需的全部细节是可见的。 ● 特定条件和时间。软件缺陷仅在特定时刻出现吗?软件缺陷在特定条件下产生吗?产生软件缺陷是网络忙吗?在较差和较好的硬件设备上运行测试用例会有不同的结果吗? ● 压力和负荷、内存和数据溢出相关的边界条件。执行某个测试能导致产生缺陷的数据被覆盖,而只有在试图使用脏数据时才会再现。在重启 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接口做管理,意味着没有标准的权限控制和操作标准流程,很容易受到攻击或者误操作。
更正统的方法是用标准的运维工具代替这些后门。
线上调试
举个例子,有次我们在进行测试环境演练,出现了个怪异的问题。后来有同事说其他一个同事也在用这个环境做调试,所以才会调用哪个接口的地方卡住,出现问题。这种问题要是出现在线上,就是故障了。
高级方法
代码走查
逻辑推理
但很多大神的解决步骤是:第一,听别人讲述问题现象;第二,提出问题以求证;第三,推理出大致原因并给出可选方案及方案的注意点;第四,自己、更多情况下是他人进行验证。为啥是他人,能达到这种境界多是领导或者帮别人排查问题的救火队长,问题发生和自己并没有直接关系。
想达到这种境界还是需要平时的积累和深入理解和深耕。源码和网络知识学起来~~
总结
一张图总结今天介绍的方法: