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