如何排查服务可用性问题——尚学堂

1.摘要

前几天做的分享，关于排查问题的过程中有可能遇到的一些场景和应对的思路。

2.背景

首先是背景介绍，之前在qcon分享上提过，这里简单介绍一下。

·业务背景：微博主要面对的是大数据量、高负载的业务压力，并且会伴随着突发的请求峰值；

·技术背景：大规模的基于linux系统的集群；使用java作为主要语言；一些外部的框架比如tomcat、storm、hbase等；一些自研的系统比如rpc框架motan、服务发现config service等。不同企业和行业采用的方案可能有区别，但从问题排查这个角度来说都是类似的。

在这个背景之上，今天要讨论的是一些影响线上服务可用性的问题，关于如何排查，和如何改进系统的一些建议。

3.排查

问题排查相对于设计系统或者编码来说是一个反向推导的过程，这个过程往往比理解原因或者解决问题复杂。

举个生活中的例子，邻居家的小孩很调皮，有一天拿弹弓玩，把我家玻璃打破了，这是个正向的推导逻辑，很好理解；但是反过来，我到回家，看到玻璃破了，想知道原因，这个过程就要复杂的多。

对于影响线上系统可用性的问题，都可以总结成这样一个模式：一个根本原因，经过一条或几条传播路径，最后表现出某些现象。

举个例子，比如由于内存泄露，导致操作系统吃swap了，导致处理变慢，导致依赖它的服务超时，导致处理线程堆积，导致服务不可用。这里的内存泄露是根本原因，服务不可用是现象，其它是传播路径。

但原因、路径和现象不是一一对应的，我在以往排查的问题的过程中，遇到的绝大多数都不是完全相同的问题，比如表现相同的问题，原因和路径完全不一样；或者相同的根本原因，通过不同路径表现出不同的现象。

还是刚才那个例子，应用吃swap的问题，可以是因为堆外内存泄露，可以是机器上启动了其它消耗内存的程序，还可以是numa配置引发的；同样，堆外内存泄露可能导致吃swap，也可能导致oom，还可能什么现象都没有。

所以单纯的看一些案例，了解“A会引发B”，对于今后问题排查来说有一些帮助，但是帮助不大，实际排查的过程中很多案例不能直接通过现象得出原因。

更进一步，可以通过某个案例去了解“在出现B现象时，我可以通过某某手段去分析”，这种学习手段的办法会好一些，但是还不够。

随着新技术的使用和越来越高的访问峰值，新的问题层出不穷，如果技术上的倾向激进一些，必然会碰到无法通过现有案例解释的问题，此时更多是学习一些解决问题的思路。

还是回到今天的分享，关于排查问题。我理解的排查就是一步步的收集线索、分析线索最终定位原因的过程，今天要讲的是如何更有效的发现和利用线索。

我在这里把线索分为三类：known-known，known-unknown，unkonwn-unknown。之后分别跟大家探讨一下每一种的应对思路和手段。

3.1.known-known

known-known，就是你想要知道，并且已经获取到的一些信息。比如日志，或者业务表现，或者监控图上反应出来的信息。

一般来说，需要获取的信息大概分几类：

1.服务表现：问题的具体表现（出错、超时等）、应用日志、依赖服务的状态等

2.系统状态：操作系统指标（系统管理的各种资源的状态、系统日志等）、vm指标（主要是gc）

3.硬件指标：cpu、内存、网络、硬盘是否达到瓶颈

我们是通过框架定制+自研/开源工具的方式来获取上面说的几类信息，比如业务相关的指标是通过框架层输出日志+ELK/graphite之类生成图形。

系统的监控用的是新浪内部的监控系统，也可以用开源的工具比如Cacti/Zabbix，运维这方面我不专业，就不展开了。

一般的监控系统应该可以提供上面这些信息，而对于分布式的系统来说，除了上面说的线索，还有非常重要的线索就是已知数据的定量分析和归类，比如：

1.重现概率

2.时间点

3.问题的共同特征

这些线索很可能因为描述的不够清楚而被忽略，但在实际排查中很可能非常有价值。

比如“不是全部请求都出错”，或者“刚才数据库和web服务都出问题了”之类，如果换成“线上请求有1/3出错，都是电信用户的请求”或者“web服务18:12:11开始报异常，数据库18:12:30开始出现慢请求”，效果是不一样的。

举个案例，以前出现过一次线上未读数偶发清不掉的问题。出现问题时没有发现明显的异常，日志也没有问题，当时我们重启了前端服务，但是没有效果。

之后我们统计了一下1分钟内出现问题的请求占正常请求的比例，大约是1/8，而这个服务依赖的另一个服务正好是8个实例，于是我们进一步统计出问题的请求，果然都调用到了同一个实例，于是当时下掉了这个可能有问题的实例，服务恢复了。

再之后通过进一步分析出问题的实例，找到了原因，那台机器在tcp超时后没有断开连接，而是直接把连接返回了连接池，导致下一次使用这个连接的时会取得上一次请求的返回值，对于计数这个场景，相当于每次返回的都是别人的数据。

总结一下关于known-known类的线索，主要是在不丢失信息的情况下，对信息做定量和归类分析，定位进一步的排查方向。