一起网线引发的血案——赵班长谈运维秒杀准时启动。我是学院高级讲师赵班长，想和大家分享一些亲身经历。“没有经历过失败的运维生涯是不完美的”——路人甲在日常的运维工作中，会遇到形形色色、甚至凌乱的失败。而且，有些失败，一开始会让你莫名其妙，结果却让人捧腹大笑。在本次分享中，我想以个人运维生涯中的两次失败作为介绍，然后谈谈失败前后我们应该做些什么。1、我刚插上一根网线，整个网络中断的环境描述的是某年的某天，机房新装了一台服务器。我们的架构是服务器连接两台接入层交换机进行端口绑定。每两个机柜都会有一个接入层交换机，所有接入层交换机，双链路都上行到汇聚层交换机。然后汇聚层切换运行MSTP+HSRP协议。架构图如下：我们的操作是增加一个接入层交换机来扩大网络规模。故障现象当时网络工程师（路人A）准备登录汇聚层Trunk交换机配置口，其他人员配合机房工作人员进行布线。我（领导不能闲着）问网络工程师插在哪里，回答：两个汇聚层交换机的23端口。谁不会插线，我就先把其中一根接入层交换机的线插到23端口。不到一分钟，QQ群里有人反映打不开网站，然后各种告警就传来了监控系统。排错1、当时我的第一反应是赶紧问网络工程师（路人A）刚才做了什么操作，他回答说刚刚登录交换机，没有进行任何操作。可以排除他的滥用。2、然后询问其他配合人员线路上有没有插拔操作，他们也回答没有。3、登录监控系统，发现报警是主机连接不上，也就是网络没有连接上，肯定是网络的原因。4.我开始思考失败前我们做了什么？我马上意识到我插了网线！虽然觉得不可思议，但是根据故障回滚的原则，我还是立马拔掉了网线。一段时间后，故障恢复正常。当时的想法是替罪羊。我决定反对。我真的很委屈！故障处理：网络工程师（路人甲）登录汇聚层交换机后，发现该交换机的23端口之前开启了portfast特性。故障原因分析：Portfast是CiscoCatalyst交换机的一个特性。在STP（SpanningTreeProtocol）中，端口有五种状态：disable、blocking、listening、learning、forwarding。只有在转发状态下，端口才能发送用户数据。一个端口连接到设备后，会经历blocking->listening->learning->forwarding，每次状态变化都需要一段时间。这样，从PC连接网线到可以发送用户数据需要等待一段时间。但如果安装了portfast，则无需等待。好了，重点来了！portfast只能用在接入层，也就是说交换机的端口必须和host相连才能开启portfast。如果接在交换机上，一定不能开启，否则会造成新的环路。（不过Cisco也提供了BPDUguard特性来解决这个问题，只是我们没有启用。）那么这个汇聚层交换机的23端口为什么要启用这个特性呢？原因是交换机之前确实有服务器接入，后来架构扩展了，只用于接入二层的接入层交换机。失败往往来得很突然，一定有各种奇奇怪怪的原因。有时甚至要你还债，“出来混，终究是要还的”。继续看下一个故障，与它无关。2、NFS故障，所有服务都down环境描述：一个APP后台API，Nginx+Python架构，本地静态文件由Nginx处理，其他请求转发到Python编写的后台API，9090端口，接入层负载均衡Nginx+保持活力。简单架构图如下：问题现象：某年某月某日某时间某后端API节点突然报错，APIhttpcode不是200。（Zabbix监控某接口Nginx代理），然后登录查看所有API服务，发现进程都在。手动测试各个节点的监控URL，发现确实无法访问。故障处理：1、查看API错误日志，未发现异常告警，也未发布新版本。2、手动测试API监听的端口，访问正常。发现直接访问Nginx代理的8080端口不正常，怀疑是Nginx与API直接通信有问题。3、此时有一个特殊情况，api-nod1节点访问正常。4、查看其他节点的Nignx错误日志，发现大量请求用户的某个URL失效。例如/user/ID/xxx5。通过对比发现，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就会根据健康检查策略判断后端服务器宕机了。然后，就没有了。不过，这次失败确实是多种因素叠加的结果。好了，篇幅问题，我们就来分析一下这两个故障，看看能学到什么。3、故障发生前我们能做什么？1.操作规范第一次失败的背景，其实我们已经制定了机房上架的操作流程。每个人都知道自己应该做什么，只是没有按照前面的去做。行动计划执行。这就是这次失败的根本原因，因为如果按照这个流程，网络工程师肯定会找出这个端口的设置并修改。另外，非实际经营者不能盲目干预。这也是操作规范的一个例子。虽然我只是想帮忙，但这是一种伤害。2、建立健全监测体系监测体系的重要性不言而喻，我就不多说了。但是就像第二个失败案例，我们有监控，但是我们遇到的问题是当告警比较多的时候，我们并没有仔细检查所有的监控，而是专注于无法连接api，而忽略了其他的告警。因此，仔细查看告警，准确归类故障非常重要。3、故障处理流程在故障发生前，需要尽可能建立完整的故障处理流程。先做什么，后做什么，故障的分类，故障的功能升级，都要有明确的流程和文档。确保故障处理人员能够合理解决故障，无法解决的及时升级故障。4、出现故障后怎么办？1、恢复是故障管理的重中之重。ITIL服务操作有一个故障管理过程。故障管理的目标是尽快恢??复正常的业务运行，将故障对业务运营的负面影响降到最低。那么，故障管理的忌讳就是试图快速定位故障原因而忽略了故障处理流程。这里有一段话可以帮助大家理解：在电子商务系统中，用户系统升级后产生了一个序列号，即用户A登录后，看到的是用户B的账户信息。问怎么办：开发人员：老大，给我10分钟，马上修复这个bug。然后开发者居然用了8分钟把代码修好了上线。结果：问题依然存在。开发主管：你水平不行，我来吧，我只需要5分钟。然后开发主管花了4分钟修复代码并上线。结果：问题依然存在。开发经理：让开，我只需要1分钟。然后开发经理真的1分钟修改代码上线。结果：问题依然存在。老板：谁能快点回复这个故障，我们都故障13分钟了！这时候，运维盔甲奋力挤进人群：我们有秒级回滚脚本，不到1分钟，所有节点回滚上一个版本启动。结果：1分钟后，故障恢复。篇幅问题，本次故障到此结束。我想不管你是老板还是管理者，开发测试运维应该都已经了解了，就不多解释了。2.故障恢复每次发生故障后，运维负责人都需要带头对故障进行恢复。开发、测试、运维必须一起review这个故障，找出问题出在哪里，如何避免此类故障再次发生。俗话说：失败是我们最好的老师。然而，每个人都不会喜欢这个老师。当然，我们还需要详细记录失败情况。3、问题管理故障恢复的目的与问题管理是一样的。在ITIL的服务运营中，问题管理流程的目标是预防问题的发生和由此产生的故障，消除重复故障，将不可预防的故障对业务的影响降到最低。因此，我们在故障恢复时，可以把这次故障转化为问题管理，综合分析故障原因，确保彻底解决，每项工作都要落实到具体负责人。推荐课程：云计算与自动化运维实践视频课程包http://edu.51cto.com/pack/view/id-298.html赵顺东人称赵班长，学院高级讲师，开设10门学院精品课程。分管武警某部队指挥自动化架构和运维工作。2008年退休后一直从事互联网运维工作。UnixHot运维社区创始人，《SaltStack入门与实践》作者。
