《Google运维解密》之问题排查

前言

今天我们来聊聊“问题排查”这个话题，本人到目前为止还在参与短网址服务一线运维的工作，遇到过很多“稀奇古怪”的线上故障和问题，结合SRE中给出的一些方法，来说说“问题排查”那点事。

排查问题不是玄学

排查出线上问题，并找到根本原因加以解决，是一件很有成就感的事情，曾经有人问过我，“你是怎么想到问题出现在xxx的？又是怎么确认根本原因是xxx的？”，我只能淡淡的说：“靠经验”，然后感觉这个逼装的自己还算满意。

其实这个“靠经验”说的很模糊，一直以来，大家都觉得排查问题要靠经验，但是又说不出具体通过啥经验排查出了问题，最后让排查问题逐渐变成了一门玄学。

排查问题犹如破案

排查线上问题，就和侦探破案一样，就是一个不停分析线索，推理的过程，在你准备破案之前，先要明确以下两点。

系统异常是正常的，正常是特例

时至今日，计算机系统已经变得异常复杂，一次用户请求可能要经过发送请求，DNS解析，运营商网络和IP转换，负载均衡，服务器硬件，虚拟机/容器,视业务逻辑的复杂程度，可能还要调用其它组件，存储，数据库，缓存等。每个环节都可能出现问题，有的组件又是分布式的，大大增加的排查问题的难度。

所以出现问题后，不要着急，保持好心态，要认为“系统异常是正常的，正常是特例”。

飞行员首要任务是保持飞机飞行

在初级飞行员的课程中捡到，在紧急情况中，飞行员的首要任务是保持飞机飞行，相比保证乘客与飞机安全着陆，故障定位和排除是次要目标。--SRE

所以，恢复线上系统是首要任务，而不是找到它发生的原因。

明确案情

先评估出这个问题的影响范围，是全网用户不可用，还是某些用户，是某条业务线出现问题，还是很多业务线都出现问题，评估出案情的大小，是普通的民事案件，还是刑事案件。

真相只有一个

计算机是一门科学，而且计算机是由0|1组成的世界，在这个世界里只有“是或否”，没有中间地带，所以在计算机世界“凡事都有根本原因”，“没有偶然发生，一切都是必然”。

所以，你要坚信真相只有一个。

理清线索

理清目前得到的线索和信息，比如监控上有网络报警，有用户反馈无法访问，有开发人员反馈服务器有问题，不要漏掉看似无关紧要的线索，把这些线索先整理下来，后面一并分析。

扩大信息量

尽可能扩大你接受到的信息量，比如问询一下开发人员今天有没有做线上改动，网络组有无重大调整。获取到有价值的信息，对于排查问题至关重要。

查看监控，细看某个监控项的变化，追踪日志和调试信息都是扩大信息量的手段。

分析证词

分析用户反馈的现象，数据是可信的，有时候人说的是不可信的，举个例子，之前有开发反馈我们虚拟机有问题，有些虚拟机接口返回异常，有些正常，他就让我们帮查查虚拟机的问题，但是最后是代码调用一处动态配置造成的。

很多反馈的信息描述，是经过描述者过滤加工过的信息，他的排查和分析有可能把你“带歪了”，先要用怀疑的态度，分析每个人的证词。

当你听到蹄子声响时，应该先想到马，而不是斑马

排查问题不要先入为主，有时候你觉得极其简单，看似非常不可能发生的事情，可能就是原因，不要轻易的排除掉某项原因，比如“宇宙射线导致某个电路信号出错”。

我们之前有个mysql连接异常的问题，查了很久，做了很多调优都没有解决，最后发现是网卡跑满了。

从大到小，从上到下

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

SRE给出的一些方法

SRE给出了一些方法可以借鉴：

• 问题排查的几个步骤：定位，检查，诊断，测试/修复，治愈。

• 什么，哪里和为什么，找出系统正在执行“什么”，询问系统“为什么”执行这些操作，以及系统的资源都被用在了“哪里”可以帮助你了解系统为什么出错。

• 确定“最后一个修改”发生的时间。

• 提供丰富的诊断和监控工具。

  
  

下次遇到问题，使用以上方法试试看，让问题排查不再是“很玄妙的东西”。