07月03, 2017

读SRE Google运维解密有感(四)-聊聊问题排查

前言

这是读“SRE Google运维解密”有感第四篇,之前的文章可访问www.addops.cn来查看。
今天我们来聊聊“问题排查”这个话题,本人到目前为止还在参与一线运维的工作,遇到过很多“稀奇古怪”的线上故障和问题,结合SRE中给出的一些方法,来说说“问题排查”那点事。

alt

题图来自500px

排查问题不是玄学

排查出线上问题,并找到根本原因加以解决,是一件很有成就感的事情,曾经有人问过我,“你是怎么想到问题出现在xxx的?又是怎么确认根本原因是xxx的?”,我只能淡淡的说:“靠经验”,然后感觉这个逼装的自己还算满意。
其实这个“靠经验”说的很模糊,一直以来,大家都觉得排查问题要靠经验,但是又说不出具体通过啥经验排查出了问题,最后让排查问题逐渐变成了一门玄学。

alt

排查问题犹如破案

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

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

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

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

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

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

明确案情

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

真相只有一个

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

理清线索

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

扩大信息量

尽可能扩大你接受到的信息量,比如问询一下开发人员今天有没有做线上改动,网络组有无重大调整。获取到有价值的信息,对于排查问题至关重要。
查看监控,细看某个监控项的变化,追踪日志和调试信息都是扩大信息量的手段。

分析证词

分析用户反馈的现象,数据是可信的,有时候人说的是不可信的,举个例子,之前有开发反馈我们虚拟机有问题,有些虚拟机接口返回异常,有些正常,他就让我们帮查查虚拟机的问题,但是最后是代码调用一处动态配置造成的。
很多反馈的信息描述,是经过描述者过滤加工过的信息,他的排查和分析有可能把你“带歪了”,先要用怀疑的态度,分析每个人的证词。

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

排查问题不要先入为主,有时候你觉得极其简单,看似非常不可能发生的事情,可能就是原因,不要轻易的排除掉某项原因,比如“宇宙射线导致某个电路信号出错”。
我们之前有个mysql连接异常的问题,查了很久,做了很多调优都没有解决,最后发现是网卡跑满了。

从大到小,从上到下

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

SRE给出的一些方法

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

  • 问题排查的几个步骤:定位,检查,诊断,测试/修复,治愈。
  • 什么,哪里和为什么,找出系统正在执行“什么”,询问系统“为什么”执行这些操作,以及系统的资源都被用在了“哪里”可以帮助你了解系统为什么出错。
  • 确定“最后一个修改”发生的时间。
  • 提供丰富的诊断和监控工具。

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

本文链接:https://www.opsdev.cn/post/sre-read-think-4.html

-- EOF --

Comments

评论加载中...

注:如果长时间无法加载,请针对 disq.us | disquscdn.com | disqus.com 启用代理。