ADDOPS团队许斯亮 360云计算
女主宣言
该文章出自于ADDOPS团队，是《Google运维解密》系列的关于问题排查的一篇分享。该文章主要是和大家聊了聊日常运维问题排查时候的一些原则与心得。推荐大家结合前面的解密系列文章一起来看，这样就能更系统的了解Google SRE在运维方面的一些精华了。希望该文章能给大家日常问题的排查能有个更好的启发。
PS：丰富的一线技术、多元化的表现形式，尽在“HULK一线技术杂谈”，点关注哦！
前言
今天我们来聊聊“问题排查”这个话题，本人到目前为止还在参与一线运维的工作，遇到过很多“稀奇古怪”的线上故障和问题，结合SRE中给出的一些方法，来说说“问题排查”那点事。
排查问题不是玄学
排查出线上问题，并找到根本原因加以解决，是一件很有成就感的事情，曾经有人问过我，“你是怎么想到问题出现在xxx的？又是怎么确认根本原因是xxx的？”，我只能淡淡的说：“靠经验”，然后感觉这个逼装的自己还算满意。
其实这个“靠经验”说的很模糊，一直以来，大家都觉得排查问题要靠经验，但是又说不出具体通过啥经验排查出了问题，最后让排查问题逐渐变成了一门玄学。
排查问题犹如破案
排查线上问题，就和侦探破案一样，就是一个不停分析线索，推理的过程，在你准备破案之前，先要明确以下两点。
系统异常是正常的，正常是特例
时至今日，计算机系统已经变得异常复杂，一次用户请求可能要经过发送请求，DNS解析，运营商网络和IP转换，负载均衡，服务器硬件，虚拟机/容器,视业务逻辑的复杂程度，可能还要调用其它组件，存储，数据库，缓存等。每个环节都可能出现问题，有的组件又是分布式的，大大增加的排查问题的难度。
所以出现问题后，不要着急，保持好心态，要认为“系统异常是正常的，正常是特例”。
飞行员首要任务是保持飞机飞行
在初级飞行员的课程中捡到，在紧急情况中，飞行员的首要任务是保持飞机飞行，相比保证乘客与飞机安全着陆，故障定位和排除是次要目标。--SRE
所以，恢复线上系统是首要任务，而不是找到它发生的原因。
明确案情
先评估出这个问题的影响范围，是全网用户不可用，还是某些用户，是某条业务线出现问题，还是很多业务线都出现问题，评估出案情的大小，是普通的民事案件，还是刑事案件。
真相只有一个
计算机是一门科学，而且计算机是由0|1组成的世界，在这个世界里只有“是或否”，没有中间地带，所以在计算机世界“凡事都有根本原因”，“没有偶然发生，一切都是必然”。
所以，你要坚信真相只有一个。
理清线索
理清目前得到的线索和信息，比如监控上有网络报警，有用户反馈无法访问，有开发人员反馈服务器有问题，不要漏掉看似无关紧要的线索，把这些线索先整理下来，后面一并分析。
扩大信息量
尽可能扩大你接受到的信息量，比如问询一下开发人员今天有没有做线上改动，网络组有无重大调整。获取到有价值的信息，对于排查问题至关重要。
查看监控，细看某个监控项的变化，追踪日志和调试信息都是扩大信息量的手段。
分析证词
分析用户反馈的现象，数据是可信的，有时候人说的是不可信的，举个例子，之前有开发反馈我们虚拟机有问题，有些虚拟机接口返回异常，有些正常，他就让我们帮查查虚拟机的问题，但是最后是代码调用一处动态配置造成的。
很多反馈的信息描述，是经过描述者过滤加工过的信息，他的排查和分析有可能把你“带歪了”，先要用怀疑的态度，分析每个人的证词。
当你听到蹄子声响时，应该先想到马，而不是斑马
排查问题不要先入为主，有时候你觉得极其简单，看似非常不可能发生的事情，可能就是原因，不要轻易的排除掉某项原因，比如“宇宙射线导致某个电路信号出错”。
我们之前有个mysql连接异常的问题，查了很久，做了很多调优都没有解决，最后发现是网卡跑满了。
从大到小，从上到下
排查步骤，先“从大到小”，先看比如运营商网络，机房状态等比较宏观的地方是否有问题，逐一排除，逐步缩小问题范围。“从上到下”，先从现象发生的顶端调用链逐一排查，逐步向下深入。
SRE给出的一些方法
SRE给出了一些方法可以借鉴：
问题排查的几个步骤：定位，检查，诊断，测试/修复，治愈。
什么，哪里和为什么，找出系统正在执行“什么”，询问系统“为什么”执行这些操作，以及系统的资源都被用在了“哪里”可以帮助你了解系统为什么出错。
确定“最后一个修改”发生的时间。
提供丰富的诊断和监控工具。
