你所须要掌握的问题排查知识

1. 说以前

           因为业务应用 bug(自己或引入第三方库)、环境缘由、硬件问题等缘由，线上服务出现故障 / 问题几乎不可避免。例如，常见的现象包括请求超时、用户明显感觉到系统发生卡顿等等。

做为一个合格的研发人员（技术人员），不只要能写得一手好代码，掌握如何排查问题技巧也是研发人进阶必须掌握的实战技能。这里提到的排查问题不只仅是在Coding的过程当中Debug，还包括测试阶段、线上发布阶段问题的排查。特别是在生产环境中，通常是没办法或很难进行Debug操做的。 而经过掌握服务线上问题排查思路并可以熟练排查问题经常使用工具 / 命令 / 平台来获取运行时的具体状况，这些运行时信息包括但不限于运行日志、异常堆栈、堆使用状况、GC状况、JVM参数状况、线程状况等。

排查出问题并找到根本缘由加以解决，实际上是一件很成就感的事情。曾经有人问过我：“你是怎么想到问题出如今xxx的？又是怎么确认根本缘由是xxx的？”，我只能轻描淡写的回答：“靠经验”，其实这里说的“靠经验”是很模糊的，一直以来你们可能都以为排查问题要靠经验，可是又说不出具体经过什么样的经验排查出了问题。而本质上排查定位线上问题是具备必定技巧或者说是经验规律的，排查者若是对业务系统了解得越深刻，那么相对来讲定位也会容易一些。排查问题的关键是什么？一句话总结：给一个系统定位排查问题的时候，知识、经验是关键，数据是依据，工具是运用知识处理数据的手段！在此，我将结合自身经历、总结，说关于“问题排查”的方法论，但愿能与您产生更多的共鸣。

 

注：因为针对不一样技术问题，所用到的排查工具，命令千差万别，因此本文将只介绍思路，不涉及具体排查命令的介绍。

 

2. 有哪些常见问题

 

        那咱们常常说遇到这样那样的问题，那到底有哪些问题，问题又集中在哪些方面？对于不一样技术框架、语言族所可能引起的问题也会存在很大的差别，但基本的套路排查思路都仍是一致的，以Java为例。

全部 Java 服务的线上问题从系统表象来看归结起来总共有四方面：CPU、内存、磁盘、网络。例如 CPU 使用率峰值忽然飚高、内存溢出 (泄露)、磁盘满了、网络流量异常、FullGC 等等问题。

基于这些现象咱们能够将线上问题分红两大类: 系统异常、业务服务异常。

 

1. 系统异常

常见的系统异常现象包括:  CPU 占用率太高、CPU 上下文切换频率次数较高、磁盘满了、磁盘 I/O 过于频繁、网络流量异常 (链接数过多)、系统可用内存长期处于较低值 (致使 oom killer) 等等。

这些问题若是是在Linux系统下能够经过 top(cpu)、free(内存)、df(磁盘)、dstat(网络流量)、pstack、vmstat、strace(底层系统调用) 等工具获取系统异常现象数据。

 

注：CPU 是系统重要的监控指标，可以分析系统的总体运行情况。对CPU的分析或监控指标，通常包括运行队列、CPU 使用率和上下文切换等，内存是排查线上问题的重要参考依据，内存问题不少时候是引发 CPU 使用率较高的主要因素。

而常常遇到内存占用飙高它的缘由可能有不少。最多见的就是内存泄露。能够获得堆dump文件后，进行对象分析。若是有大量对象在持续被引用，并无被释放掉，那就产生了内存泄露，就要结合代码，把不用的对象释放掉。

 

2. 业务服务异常

常见的业务服务异常现象包括: PV 量太高、服务调用耗时异常、线程死锁、多线程并发问题、频繁进行 Full GC、异常安全攻击扫描等。

频繁的 GC 将致使应用吞吐量降低、响应时间增长，甚至致使服务不可用。

 

3.问题排查方法论

1、排查问题犹如破案

排查线上问题犹如警察破案同样，是一个不停分析线索，推理的过程，但在准备排查问题以前，咱们应该明白三个认知:

• 系统出现异常是正常的

        时至今日计算机系统已经变得异常复杂，一次用户请求可能要通过发送请求，DNS解析，运营商网络，负载均衡，服务器，虚拟机（容器），视业务逻辑的复杂程度可能还要调用组件，缓存，存储和数据库等。每一个环节均可能出现问题，有的组件又是分布式的，大大增长的排查问题的难度，因此出现问题后不要慌，保持好的心态。

 

• 首要任务是恢复系统

      飞机在发生紧急状况下，飞行员的首要任务是保持飞机飞行，相比保证乘客与飞机安全着陆，故障定位和排除是次要目标”，因此恢复线上系统是首要任务，而不是立马找到它发生的缘由。

• 真相永远只有一个

 

       计算机是一门科学，并且计算机的世界里都是由0或1组成，在这个世界里只有是或否，没有中间地带，因此在计算机世界凡事都有根本缘由，没有偶然发生，一切都是必然。正如墨菲定律所提到的“若是事情有变坏的可能，无论这种可能性有多小，它总会发生！”

 

2、了解案情，评估大小

     先评估出这个问题的影响范围，是全网，某些地区，仍是某条链路不可用的问题，仍是不少业务线都出现问题，评估出案情的大小，究竟是普通的民事案件，仍是刑事案件。

 

3、理清线索，整理分析

     理清手头已获得的信息或线索，好比监控上有网络报警，有用户反馈没法访问，有开发人员反馈服务器有问题，同时间段有作变动等等，尽可能不要漏掉这些看似可有可无的线索，把这些线索先整理下来，后面一并分析。

推理的过程，就是根据已知线索，经过合理的想象、推断得出一个惟一的结果。线索是整个推理过程的起点，线索给出的好有很差、是否有错误，直接会影响推理的质量，所以是最基础、也是最重要的一环。线索的梳理，最常犯错误就是信息不足，主观臆断。

其中整理分析过程当中，很重要的一点：尽量搞清楚问题的来龙去脉！

    不要一会儿就扎到服务器前面，你须要先搞明白对这台服务器有多少已知的状况，还有故障的具体状况。否则你极可能就是在无的放矢。

必须搞清楚的问题有：

• 故障的表现是什么？无响应？报错？

• 故障是何时发现的？

• 故障是否可重现？

• 有没有出现的规律（好比每小时出现一次）

• 最后一次对整个平台进行更新的内容是什么（代码、服务器等）？

• 故障影响的特定用户群是什么样的(已登陆的, 退出的, 某个地域的…)?

• 基础架构（物理的、逻辑的）的文档是否能找到?

• 是否有监控平台可用? （好比Munin、Zabbix、 Nagios、 New Relic… 什么均可以）

• 是否有日志能够查看?. （好比Loggly、Airbrake、 Graylog…）

另外也能够进一步从应用层、数据库层、网络层进行检查：

应用层：

• 应用最近是否有上线？

• 软硬件环境最近是否有变动？

• 应用日志是否有异常？

• 重启是否有效？

数据库：

• 数据库系统级配置最近是否有变动？

• telnet端口是否畅通？

• tnsping监听是否正常（连通性、延迟）

• 数据库是否有异常的等待？

• 远程、本地SQL执行是否正常？

网络：

• 网络最近是否有变动?

• ping是否正常？

• traceroute -l 是否正常？

• 网络是否有丢包、延迟？

尽量地获取到更多的已知有效信息，汇总信息并从多条排查线去进行分析，这里推荐思路有：

• 经过变动记录来咨询相关人员，大量问题其实都是上线、变动等引发的，因此排查下同时期有过业务相关的变动操做人员，每每就能够把不少问题排除在这道线上了。

• 经过日志、数据等，把一些已知问题筛选出来。

• 经过影响人群、问题点等信息尝试找出复现方法。通常来讲，能有方法稳定复现的问题，就比较容易排查到了。

• 到这一步的问题，基本上都属于一些疑难杂症了，就没有一些特别通用的方法了。须要开阔思路，找找规律，将平时没关注到的技术、业务点再了解的更细致，更深刻一些，或者求助于团队的帮助一块儿来解决。

须要注意一点：经过分析日志时，业务日志除了要关注系统异常与业务异常以外，还要关注服务执行耗时状况，耗时过长的服务调用若是没有熔断等机制，很容易致使应用性能降低或服务不可用，服务不可用很容易致使雪崩。若是没办法直接从日志中发现异常，那就只能看看应用到底在干吗了（可分析应用在异常时期的线程内存堆栈信息）。

 

这一步原则很简单：找出系统正在执行“什么”，询问系统“为何”执行这些操做，以及系统的资源都被用在了“哪里”能够帮助你了解系统为何出错。

 

4、扩大你的信息量

      主动扩大信息的接收面，好比问询一下开发或其它相关同窗，今天有没有作线上改动，网络组有无重大调整。从中获取到有价值的信息点，对于排查问题相当重要。查看监控，细看某个监控项的变化，追踪日志和调试信息都是扩大信息量的手段。

拓展知识面，闲暇时间多些了解相关联系统，好比架构，部署，逻辑等。一旦故障发生，讨论中也可提供你解决办法的思路，触类旁通，推动问题的排查与解决。

收集问题及环境信息，须要收集的信息可能有：

• 问题的已知首次发生时间

• 问题反馈人员所处的环境，例如省、市、ip、ISP、浏览器、手机型号、app 版本等

• 问题是全员的仍是部分的。

• 问题发生在哪些服务器上。

• 同期相关的日志、数据信息。

• 同时期的上线、配置变动、运维操做、基础服务变动等记录。

• 同时期基础服务提供商的变动、故障公告等。

 

5、分析证词，甄别对错

      若是是外部提出的问题，好比业务投诉，用户反馈等信息，有时候是可信的，有时候人倒是不可信的，举个例子以前有开发反馈效果有问题，有些广告位bias异常，有些正常，让咱们帮查查系统的问题，可是最后是代码调用一处动态配置形成的。有些时候反馈的信息，是通过描述者过滤加工过的信息，他的排查和分析有可能把你带偏了，在收集信息同时须要以审视、怀疑的态度，分析每一个人的证词。

 

6、看清问题本质

    “当你听到蹄子声响时，应该先想到马，而不是斑马”，看到一件现象或一件事情，要看实质而不仅是表面的东西，听到马蹄声时候猜是什么马，是什么人的马，是来干什么的而不是猜它是斑马仍是白马仍是黑马。排查问题也同样切忌先入为主，有时候你以为极其简单，看似很是不可能发生的事情，可能就是缘由，不要轻易的排除掉某项缘由。例比：以前遇到有个mysql链接异常的问题，查了好久，作了不少调优都没有解决，最后发现是网卡跑满了。

 

7、肯定方向，开展定位

      排查步骤，能够先“从大到小”，先看好比运营商网络，机房状态等比较宏观的地方是否有问题，逐一排除，逐步缩小问题范围。再“从上到下”，先从现象发生的顶端调用链逐一排查，逐步向下深刻。

但也并非全部问题都从大到小从上到下，宏观问题只有达到必定量级才会引起”质变”，从而引发的注意，在通往质变过程当中，你的业务可能已经收到某中影响而表现的很明确，此时须要微观分析，而后再逐渐到宏观来诊断。

 

8、卷宗记录，破案归档

问题排查解决后，养成过后总结的习惯。好记性不如烂笔头，然而在一片混乱问题分析当中，心平气和地记录下问题与判断确实有点不切实际。但即便如此，咱们仍然能够在事情结束后为保留一份分析资料，总结并记录处理过程当中的执行步骤以及解决途径，则能帮助本身和团队积累宝贵的处理经验。

 

• 对于我的

       一次问题的定位解决每每伴随着我的的成长，咱们不要放弃这样的机会。在追查过程当中了解的知识点是比较零碎的，不系统。过后就须要你们将这些点总体串起来，而且以点带面，将知识点变动知识面。

 

• 对于团队

 

1. 是对此次问题的反思，咱们应该在流程、代码、工具或者哪些方面作出调整，能够更好的避免同类型问题的出现。

2. 是对追查过程的总结，在问题定位的过程当中，咱们缺乏哪些帮助及工具的支持，可否更好的提高排查问题的效率，而后相关人员是否对过程结果存在异议。

 

4. 长期改进建议

    吃一堑长一智出了问题并不可怕，怕的是咱们从问题中学不到什么，怕的是相似的问题重现，提升问题定位的效率，有哪些值得去作，好比：

 

一、创建长效错误码机制，使用具统计、可视意义的数字来简短描述错误含义和范畴，正所谓浓缩就是精华，这一点在错误码屡试不爽。

二、正常程序中打错误日志主要是为了更好地排查问题和解决问题，提供重要线索和指导。可是在实际中打的错误日志内容和格式变化多样，错误提示上可能残缺不全、没有相关背景、不明其义，使得排查解决问题成为很是不方便或者耗时的操做。而实际上只要开发稍加用心，也需就会减小排查问题的不少无用功。如何编写有效的错误日志，创建日志标准，也是很是有利于问题分析的。

三、定位问题避免二次损害，当某个看似难以捉摸的难题出现时，本能多是重启，尽快让系统恢复正常。虽然这样的方式常常可以解决问题并且起效神速，但同时也极可能把状况推向使人难以置信的恶化深渊。问题排查手段包括从新启动不稳定系统、尝试自动记录数据库、文件系统修复等等，这些方式每每确实能搞定难题并让系统重回生产轨道，但同时也没准致使数据恢复努力付之东流，毁掉肯定问题根本缘由的机会甚至大大延长关键性系统的停机时间。保留现场也很是重要，跟破案现场要要求现场勘察、样本采集、排查、锁定一模一样，对于难以重现问题，尽可能创造条件保留了能够用于故障重现的数据或现场。线上环境复杂多变，虽然这一点并不能立刻解决问题起到直接做用，但坚持这种处理思路，为开发和测试创造条件，下降因难以重现的疑难故障的挂起率，最终有助于业务的长期稳定。

四、创建集中的数据可视平台，不至于遇到问题才开始着手分析，如果对业务没有足够的了解又没有数据依赖，就极可能在解决问题时雪上加霜。

五、创建沙箱影子系统，模拟复杂多变的现网环境，规避线上影响，重现或压测问题，如tcpcopy、dubbocopy等。

六、搭建开源的日志可视方案，协助咱们去解决最后”一千米”的问题，常见如ELK、Log.io等。

七、善其事必先利其器，常见系统排查工具perf、iptraf、netperf、tcpdump、gdb、pstack、jstack、strace，top、iotop、tsar等。

八、在升级版本或者替换或修改文件时，必定要作好备份，要保证随时能够还原。

九、程序在使用多线程时，尽量的减小多线程竞争锁，能够将数据分段，各个线程分别读取。

十、尽可能不要在线程中作大量耗时的网络操做，如查询数据库（能够的话在一开始就将数据从从 DB 中查出准备好）。

十一、建议对线程取一个有意义的名称，这样对于在排查问题时颇有必要，如当拿到程序线程堆栈信息时，可直接根据线程名在日志中找到相关的堆栈。

十二、生产环境进行问题排查时必定要保证不要影响正常的业务执行。

 

原文连接：技术大全-公众号：mikezhou_talk【你所须要掌握的问题排查知识】