1.摘要

前几天在高可用架构群里做的分享，关于排盘查题的进程中有大概碰着的一些场景和应对的思路。

2.配景

首先是配景先容，之前在qcon分享上提过，这里简朴先容一下。

在这个配景之上，本日要接头的是一些影响线上处事可用性的问题，关于如何排查，和如何改造系统的一些发起。

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开始呈现慢请求”，结果是纷歧样的。

举个案例，以前呈现过一次线上未读数偶发清不掉的问题。呈现问题时没有发显着显的异常，日志也没有问题，其时我们重启了前端处事，可是没有结果。