线上系统性问题定位与方法论

1、白鸽学胆线上系统性问题定位与方法论Image Todaytsi；鸽学吧前言一线程序员在工作中经常需要处理线上的问题或者故障，但工作几年下来发现，有些同事其实并不知道该如何去分析和解决这些问题，毫无章法的猜测和尝试，虽然在很多时候可以最终解决问题，但往往也会浪费大量的时间，时间就是金钱，对线上系统而言甚至是生命。本文尝试将本人工作过程中对线上问题的处理经验加以总结精炼，并给出一套相对有规律的问题定位处理模式，希望能够在排查问题的过程中可以帮助大家节省一些时间，尽快找出问题的关键点并修复。了解你的系统什么样的现象应该列为“系统问题”？某个服务的QPS达到1000 ?对于一般系统或许算是，但是对大型

2、电商网站，或许这只是常态。很显然对于不同规模，不同功能的系统，这个问题无法一概而论。因此快速发现问题的前提是深入了解你的系统。通常情况下，我们可以把系统简单的划分为下面三个层次：2tsi；鸽学吧系统层也就是我们的部署软硬件环境。通常包含CPU、磁盘、内存、网络IO等。我们的系统是分布式的，还是单机应用？ CPU是几核的？物理机还是虚机？内存、磁盘是多大？网卡的规格？软件层也是我们部署的软件环境。 负载均衡服务器？ JDK版本？ web服务器（Tomcat等）以及JVM参数设置?数据库、缓存使用的是哪种产品？应用层也就是我们的系统本身。关键接口的平均响应时间（RT）是多少？服务的 QPS是多少？

3、某个接口的并发数能承受多少？tsi；鸽学吧以上这些问题你是否能回答出来？这些问题的了解多寡，决定了你对系统的熟悉程度，也在很大程度上决定了你能否及时的发现问题，甚至在其真正造成影响之前就将问题解决。现在你或许能回答：某个服务的QPS达到1000 ,究竟算不算是线上问题。评估问题影响范围一个问题究竟影响了多大范围的用户？在多大程度上影响用户的正常使用？如果是集群系统，那么这个问 题是全局性的还是只在单台机器上出现？不同的问题范围会直接影响到问题处理的优先级，一些极端情况 下的个案，甚至可以不急于处理（至少不用过于焦虑）。问题信息的搜集来源，有如下途径：系统、业务监控报警一般稍微上规模的公司，都会

4、有配套的监控系统，通常监控系统报警都意味着问题已经影响到系统的正常运行了，此时属于比较严重的生成事故，需要第一时间处理。此类问题由于可以重现，因此比较容易排查。关联系统故障追溯关联系统发现问题，通过追溯发现是由本系统的问题引发的，此时问题的触发的往往已经比较明确，需要 根据关联系统的故障程度决定问题处理的优先级。但此类问题很容易牵扯出隐藏的其他问题（如系统改造 时沟通不善造成的适配问题等），紧急修复后还需要进行进一步仔细排查。生产事件上报（客服上报）此类问题往往来自用户投诉，最重要的就是问题现象的复现。主动发现通过线上监控，或者日志，主动发现线上系异常的情况。需要确认是否是问题，可能只是偶发性

5、的系统抖 动。tsi；鸽学吧快速恢复说回问题本身，一旦确定是系统bug ,该如何处理？立即去检查代码？且不说线上bug往往不那么容易 检查出来，及时能够快速定位，修复又会耗费大量时间，这期间不知有多少用户受到影响。线上问题处理的核心是快速修复。有以下两类处理方案:1.无法快速定位到问题根源回滚：当最近有新版本上线时，多半首选这种方案重启：CPU高，或者连接数飙升时，会采取这种方法扩容：线上访问压力大，重启也无法解决时2.可以定位到问题点的临时方案或者功能降级无论哪种方式，目标都是以最快速度恢复服务。但这种方式是临时的，为了彻底解决问题，都需要保留事 故现场。基本方式如下：a.执行top命令，若

6、CPU空闲程度较低：shift+p 按CPU使用率倒排，记录最耗资源的进程信息。b.执行free -m命令，若内存使用量高：执行 top , shift+m 按内存使用率倒排，记录最耗资源的进程 信息。c.对嫌疑进程执行psxuf | grep java，打印进程详细信息并记录。d.使用jstackjstack.log收集线程信息（反复多取几次）。e.使用jstat -gcutil查看Old区占用率，对接近 100%的进程执行jmap jmap.log 保留内存信息。定位与修复下图展示了常规情况下我们系统故障的原因：白鸽学吧 REBELLABS mA vi iMStoMiWMabbihifti

7、 panv eni ：hfWhat are the typical root causes图i-系统故障原因由此可见，多数情况下，系统的故障都会反映为系统的一项或者多项指标异常。如最初所说，我们可以将整个系统抽象成为几个模块，那么对应的，每个模块也有一些工具供我们进行问题的分析与定位。Laof pest*t pldctataa Dpa： ng Sr s?itHanhkvv natstdt y ad-ig/procdttprf七工英七命1 ttngsbpf古户伯 rC* IZerfx，ila SystemsTCFflJDFirrxi MFinsgorIhmK3piditatMflrncry be

8、 vice ftnvarsIX?ra* t*tslabtapf rDRAMblttra力以下是常见的问题排查工具箱:CPU : top -Hp系统内存：free -mIO ： iostat磁盘：df -h网络链接：netstatgc: jstat-gcutil1/Q丽白弊iptraf t ypdspBUIUSAt图2-Linux常用工具集线程：jstackJava 内存：jmap辅助工具：MAT , btrace , jprofile具体的使用方法不再赘述方法论有了基本的系统模块划分，以及每个模块对应的分析工具，我们可以尝试将问题的排查抽象成一个相对固 定的流程。大致的思路是：先逐个模块排查，

9、确认问题现象再根据问题现象，定位问题进程进一步分析线程以及内存情况最终找到问题的触发点。10基本流程如下图所示:白鸽学胆图3-逐步排查，锁定问题进程11图4-详细分析目标进程为故障与失败做设计随着系统规模的逐渐扩大，更多的功能被引入，更多的代码被添加进来，从这个角度来看线上的问题几乎 是无可避免的。以上说的都是问题发生后的消极应对措施。事实上，无论我们的设计多么的完善，故障仍 然是无法避免的。而且大多数时候，失败、故障都会从一个我们无法预期的角度发生，令人猝不及防。因此在系统架构时需要设计一种机制，使得失败、故障发生时能将系统的损失降到最低，在故障发生时尽 可能维持核心功能的可用性。12m鸽学岷.设置合理的超时机制处理网络上第三方依赖时，需要对接口的响应时间有一个合理预期，当请求超时时能够主动断开连接，避免请求堆积。 本地服务相互调用时也需要合理的设置超时时间。.服务降级对于无