其他分享
首页 > 其他分享> > 排查线上问题的9种方式

排查线上问题的9种方式

作者:互联网

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

 

斯坦门茨在电机旁仔细观察,经过计算,用粉笔在电机外壳划了一条线,说:“从这里打开,把里面的线圈减少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接口做管理,意味着没有标准的权限控制和操作标准流程,很容易受到攻击或者误操作。

 

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

 

线上调试

 

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

 

高级方法

 

代码走查

 

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

 

逻辑推理

 

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

 

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

 

总结

 

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

标签:方式,步骤,问题,排查,软件缺陷,线上,埋点,日志
来源: https://www.cnblogs.com/xiexj/p/16159139.html