转载

一根网线引发的血案-赵班长谈运维

--运维的故障哲学

51CTO学院IT课程1折起秒杀， 12月12日0点万人秒杀准时开启 ，我是51CTO学院高级讲师赵班长，跟大家分享一些个人经验。

“没有经历过故障的运维生涯是不完美的”--路人甲

在我们日常运维工作中，会遭遇各种各样，甚至乱七八糟的故障。而且有些故障刚开始会让你莫名其妙，但结果却让人苦笑不得。这次分享，我想通过阐述个人运维生涯中的其中两个故障作为引子，进而聊聊发生故障之前和之后，我们应该怎么办。

一、我只是插了一个网线，全网中断

环境描述

某年某月某日，机房上架新的服务器。我们的架构是服务器上联两台接入层交换，做端口bonding。每两个机柜都会有接入层交换机，所有接入层交换，双链路上联到汇聚层交换中。然后，汇聚层交换运行MSTP+HSRP协议。架构图如下：我们的操作是要新增一个接入层交换，用来扩展网络规模。

一根网线引发的血案-赵班长谈运维

故障现象

当时网络工程师(路人甲)正在准备登录汇聚层交换配置端口Trunk，其他人员配合机房工作人员走线，当接入层交换的上联网线拉到汇聚层交换机的机柜的时候，作为负责人的我(领导不能闲着啊)就问网络工程师插哪里，回复：两台汇聚层交换的23端口。

插线谁不会啊，于是我就先把其中一根接入层交换机的线，插入了23端口。刚过去不到一分钟，QQ群就有人反映打不开网站了，紧接着监控的系统各种报警就来了。

故障处理

1. 我当时的第一反映，赶紧询问网络工程师(路人甲)刚才执行了什么操作，回复刚登录到交换机上还没有操作。可以排除他的误操作。

2. 然后询问其他配合人员是否在线路上有插拔操作，同样回复没有。

3. 登录监控系统，发现报警的是主机无法连接，也就是网络不通，肯定是网络方面的原因。

4. 开始思考在故障之前我们都干了什么?我马上反映过来，我插了一根网线!虽然觉得不可思议，但是根据故障回滚的原则，我立即把网线拔掉，过了一会，故障恢复了。当时的想法就是这个黑锅，我背定了，真心冤啊!

故障排查：

网络工程师(路人甲)，登录汇聚层交换后，发现该交换机的23端口之前开启了portfast特性。

故障原因剖析：

Portfast快速端口是一个Cisco Catalyst交换机的一个特性，在STP(Spanning Tree Protocol)中，端口有5个状态：disable、blocking、listening、learning、forwarding，只有forwarding状态，端口才能发送用户数据。

一个端口接入设备后，就会经历blocking->listening->learing->forwarding，每个状态的变化要经历一段时间。这样从pc接上网线，到能发送用户数据，需要进行等待的时间。但如果设置了portfast，那就不需要等待了。

好的，重点来了!portfast只能用在接入层，也就是说交换机的端口是接主机的才能启用portfast，如果是接交换机的就一定不能启用，否则会造成新的环路。(不过，Cisco也提供了BPDU guard特性解决这个问题，但是我们没有启用。)

那么为什么，这个汇聚层交换的23端口会开启这个特性呢?原因是之前这个交换机确实有服务器接入，后来架构拓展了，才只用来接入二层的接入层交换机。

故障经常就是来的很突然，而且肯定会有各种奇葩的原因。甚至有的时候就是让你还债，还是那句话“出来混，终究要还的。”我们继续看下一个故障，直接没有任何关联性。

二、NFS故障，服务全部宕机

环境描述：

某APP后端API，Nginx+Python的架构，本地静态文件由Nginx处理，其他请求转发到后端Python编写的API上，端口9090，接入层负载均衡Nginx+Keepalived。简单的架构图如下：

一根网线引发的血案-赵班长谈运维

故障现象：

某年某月某日某时突然某后端API节点报警，API http code not 200。(Zabbix监控Nginx代理的某个接口)，然后登陆查看所有API服务，发现进程都在。手动测试每个节点的监控URL，发现确实无法访问。

故障处理：

1.查看API的错误日志，并未发现特别异常的报警，并没有新版本发布。

2.手动测试API监听的端口，访问正常。直接访问Nginx代理的8080端口，发现不正常，怀疑Nginx和API直接的通信存在问题。

3.这时有一个特殊情况就是api-nod1节点的访问时是正常的。

4.查看其他节点的Nignx错误日志，发现有大量的请求用户的一个URL失败。例如/user/ID/xxx

5.通过对比发现api-node1和其他节点的唯一不同是api-node1节点运行了NFS，其他节点之前是挂载该节点的NFS。原因是：后端API会生成二维码在各个服务器上，由于数据量不大，所以在api-node1节点启动了NFS，其他所有节点生成的二维码全部写入到这个NFS共享上。查看发现该节点的NFS异常终止。手动启动NFS和重启所有API节点后，服务恢复正常。

故障原因剖析：

通过仔细查看报警才发现，之前api-node1这台虚拟机因为内存跑满自动重启了，但是NFS并没有开机启动(这个是另外一个问题，暂不讨论)，因为当时报警太多就没有仔细看每个报警。那么，为什么NFS故障会导致api不能访问呢?应该是某个接口功能不能使用才对。

经过分析，这个功能是用户用来生成二维码的接口，如果用户发现生成失败会不停的重试，那么这些重试的api就会到nginx上，当然肯定都会失败，因为NFS无法读写。但是，我们知道Nginx做后端健康检查默认是无法指定URL的，突然这么多重试的API请求到达Nginx都失败了，那么Nginx根据健康检查策略就会认为后端服务器宕机。然后，就没有然后了。不过，这个故障确实是多种因素叠加的一个效果。

好的，由于篇幅问题，就拿这两个故障，来进行分析，看看我们能学到什么东西。