IT故障排查思路和方法交流

1.故障处理原则

首要原则：

生产环境优先恢复业务（比如重启服务、修改负载均衡指向、恢复原有程序包等）；保留现场以备查找故障原因

a.遇到问题不要慌；理清思路；

b.首先要自行排查，不要遇到问题就甩到研发。

c.没有查出原因不要轻易下结论。

d.自己无法解决；及时上升问题到二线或领导。

2.故障等级和SLA

   

故障等级	影响范围	要求解决时间
轻微故障	影响较小，不影响使用	24小时
一般故障	影响一般，影响客户感知	4小时
重大故障	影响重大，严重影响客户使用	2小时

根据如上故障等级，需要大家及时响应和解决问题，自己无法解决时，及时寻求二线支持，同时上报给领导。

3.故障处理思路

a.理清网络拓扑图和数据流向

b.分析问题产生的可能原因

c.从可能原因一个一个排查

d.根据排查结果；给出解决办法

4.故障处理方法

 可以从如下几个方面对故障产生的原因进行分析；然后逐项排查。

4.1从操作角度进行分析

近期是否进行过变更操作

案例：

   某项目各服务一直稳定运行，6月3日进行了某个程序升级操作；6月5日发现服务器内存占满，ssh无法登录。

排查思路：

a.重启服务器之后查看系统日志；发现系统出现oom告警，报错无法分配更多的内存

b.查看Prometheus监控发现，某程序在升级完之后占用内存一直在增多；最终导致oom

c.联系研发修改该程序相关代码之后重新升级，问题解决。

4.2 从数据流向进行分析

通常部署在云平台上的系统，网络相对比较复杂，服务之间调用关系比较多，出现故障以后难以定位；因此需要从数据流向的角度去逐一排查相关问题。

案例：

某项目大屏点击视频播放窗口，视频出现卡顿现象；由于该项目涉及到的云平台和网络区域较多；服务之间调用也很复杂；

排查思路：

1. 首先梳理点击视频播放的数据流向，明确各服务之间调用关系
2. 检查各服务之前网络带宽、时延、抓包分析
3. 检查中间件参数配置
4. 检查服务端服务状态是否异常

问题：如何梳理网络拓扑或者服务数据流向？

1. 项目验收前梳理出相关资料
2. 项目验收后还没有输出资料的，可以在需要的时候拉着研发，通过查看相关文档，查看配置文件梳理。

      

4.3 从原理角度进行分析

   原理是处理问题的核心所在，熟练掌握中间件的工作原理，在处理故障的时候才能得心应手。

案例：

   某项目服务器断电重启；导致k8s集群无法正常启动;kubectl get node 发现两个node节点not ready。

node节点ready的前提是条件docker、kubelet、网络插件都正常；检查kubelet日志发现提示如下两个报错：

1. failed to get docker version: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

1. Failed to run kubelet" err="failed to run Kubelet: running with swap on is not supported, please disable swap! or set --fail-swap-on flag to false. /proc/swaps contained: [Filename\t\t\t\tType\t\tSize\tUsed\tPriority /dev/zram0   

根据以上两个报错，启动docker和禁用swap；同时记得把这两项加入开机启动。

4.4从服务运行角度进行分析

a.检查内存、cpu、磁盘IO 网络等资源占用情况

b.检查API、进程、端口 是否正常。

   附相关命令：

检查内存

free -h

查看监控图像

通过上图可以获取每个进程在某个时间点或一段时间的内存占用情况

检查当前1分钟内 内存使用情况排名

top -bc -o +%MEM n 60| head -35|awk '{print $1,"     "$9,"    "$10,"    "$12}'|awk 'NR==6,NR==13  {print}'

检查1分钟内CPU使用排名

top -bc -o +%CPU n 60| head -35|awk '{print $1,"     "$9,"    "$10,"    "$12}'|awk 'NR==6,NR==13  {print}'

检查API返回码

curl -I -m 10 -o /dev/null -s -w %{http_code} http://127.0.0.1:9100/metrics

检查进程

pa -eaf|grep nginx

检查TCP端口

ss -ntlp|grep nginx

netstat -anp|grep nginx

检查udp端口

netstat -ntup

测试tcp端口连通性

    telnet 150.236.211.171   161

测试udp端口连通性

nc -vuz  150.236.211.171   161

4.5从日志角度进行分析

从日志下手，是我们排查故障最有效的手段（没有之一）。上述排查问题的方法最终无一例外都是通过日志进行的。日志类型一般分为如下三种；

a.中间件日志

b.应用程序日志

c.系统日志

针对中间件和系统的的报错，方法如下：

a.自行解决

b.百度

c.拷贝报错关键字（不要截图）发给二线支持

针对应用程序的报错，方法如下：

1. 拷贝报错关键字（不要截图）或者把日志打包发给研发分析

检查日志，通过日志找到报错关键字

error 、time out 、not found、not permited、not match、not support，not exits；

duplicated ；Permission denied；failed；Out of memory；unknown；no such file；

附：相关命令

查看系统日志命令

tailf /var/log/messages

查看kubelet服务日志

journalctl -xefu kubelet

4.6查看监控日志

针对已经zabbix 或Prometheus监控的系统，通过查看其监控记录，也是排查故障最为行之有效的方法之一。

如上图，详细的记录了系统整体内存、CPU使用情况和某个进程内存、CPU使用情况，我们可以根据上述数据很快定位出问题进程号，然后查看相关日志综合分析得出结论。

5.故障处理流程

6.如何寻求帮助

首先自己已经排查，但是无法定位问题，然后才寻求二线或者研发支持，必要时组织相关会议；需要把问题描述清楚：

1. 故障现象描述
2. 前后有没有做操作
3. 网络拓扑和服务调用关系
4. 自己的排查思路和结果

7.二线快速介入需要的材料

1.  项目基础信息表
2. 网络拓扑图
3. 生产环境故障处理工单

8.如何写故障处理报告

a问题现象

b.产生原因分析

c.排查过程和证据

d.解决办法

c.优化方案和避免问题再次发生