• 欢迎访问安全专题网站,安全专题信息,安全专题教程,推荐使用最新版火狐浏览器和Chrome浏览器访问本网站,欢迎加入安全专题 QQ群
  • 安全专题现已支持滚动公告栏功能,兼容其他浏览器,看到的就是咯,在后台最新消息那里用li标签添加即可。
  • 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏安全专题吧

艾玛,全网故障?!我只是插了一根网线!

安全运维 网络收集 2年前 (2016-12-23) 227次浏览 0个评论

艾玛,全网故障?!我只是插了一根网线!

作者简介

赵舜东,江湖人称赵班长,曾负责武警某部指挥自动化架构和运维工作,2008 年退役后一直从事互联网运维工作。UnixHot 运维社区创始人、《SaltStack 入门与实践》作者。

引言

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

在我们日常运维工作中,会遭遇各种各样,甚至乱七八糟的故障。而且有些故障刚开始会让你莫名其妙,但结果却让人苦笑不得。

这次分享,我想通过阐述个人运维生涯中的其中两个故障作为引子,进而聊聊发生故障之前和之后,我们应该怎么办。

案例 1:我只是插了一根网线,全网中断!?

1.环境描述

某年某月某日,机房上架新的服务器。我们的架构是服务器上联两台接入层交换,做端口 Bonding 。

每两个机柜都会有接入层交换机,所有接入层交换,双链路上联到汇聚层交换中。然后汇聚层交换运行 MSTP+HSRP 协议。

架构图如下:我们的操作是要新增一个接入层交换,用来扩展网络规模。

艾玛,全网故障?!我只是插了一根网线!

2.故障现象

当时网络工程师(路人甲)正在准备登录汇聚层交换配置端口 Trunk,其它人员配合机房工作人员走线。

当接入层交换的上联网线拉到汇聚层交换机的机柜的时候,作为负责人的我(领导不能闲着啊)就问网络工程师:插哪里?回复:两台汇聚层交换的 23 端口 。

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

3.故障处理

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

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

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

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

4.故障排查

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

5.故障原因剖析

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 端口会开启这个特性呢?原因是之前这个交换机确实有服务器接入,后来架构拓展了,才只用来接入二层的接入层交换机。

小结

故障经常就是来的很突然,而且肯定会有各种奇葩的原因。甚至有的时候就是让你还债,还是那句话“出来混,终究要还的。”

我们继续看下一个故障,之间没有任何关联性。

案例 2:NFS 故障,服务全部宕机

1.环境描述

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

艾玛,全网故障?!我只是插了一根网线!

2.故障现象

某年某月某日某时突然某后端 API 节点报警:API http code not 200。(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 并没有开机启动(这个是另外一个问题,暂不讨论),因为当时报警太多就没有仔细看每个报警。

那么为什么 NFS 故障会导致 api 不能访问呢,应该是某个接口功能不能使用才对?

经过分析,这个功能是用户用来生成二维码的接口,如果用户发现生成失败会不停的重试,那么这些重试的 api 就会到 nginx 上,当然肯定都会失败,因为 NFS 无法读写。

但是我们知道 Nginx 做后端健康检查默认是无法指定 URL 的,突然这么多重试的 API 请求到达 Nginx 都失败了,那么 Nginx 根据健康检查策略就会认为后端服务器宕机。然后就没有然后了。。。

不过这个故障确实是多种因素叠加的一个效果。

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

反思:故障发生前我们能做什么?

1.操作的规范性

第一个故障的背景,其实我们已经制定好了机房上架的操作流程,每个人都知道自己应该干什么,但是并没有按之前的操作计划执行。

这是发生这个故障的根本原因,因为如果按流程,网络工程师肯定会发现这个端口的设置并修改。

还有就是非实际操作人员不能盲目介入,这也是操作规范性的一个例子,虽然我只是想帮个忙而已,但是帮了倒忙。

2.建立完善的监控体系

监控体系的重要性不言而喻,不准备多说。但正如第二个故障案例,我们有监控,但是遇到的问题是当报警很多的时候,并没有仔细的查看所有监控,而是把 api 无法连接当作重点,而忽略了其它报警。

所以说,仔细的看报警,以及给故障进行准确的分级非常重要。

3.故障处理流程

在发生故障前要尽可能的建立完善的故障处理流程,先干什么,后干什么,故障的分级、故障的职能性升级都要有确切的流程和文档。保证故障的处理人能够合理的将故障解决,不能解决的及时进行故障升级。

反思:发生故障后,我们能做什么?

1.恢复是故障管理的第一要务

ITIL 的服务运营有一个故障管理的流程,故障管理的目标是尽可能快地恢复到正常的服务运营,将故障对业务运营的负面影响减小到最低。

那么故障管理的大忌,就是试图快速定位故障原因而忽略了故障处理流程。下面有个小段子,可以帮助你理解:

某电商系统,一次用户系统升级,导致串号,也就是用户 A 登录后,看到的是用户 B 的帐号信息。

领导问:怎么办?

开发人员:老板,给我 10 分钟,马上修复这个 bug。

然后开发人员实际使用了 8 分钟修代码并上线。结果故障依旧!

开发主管:你这水平不行啊,我来,我只需要 5 分钟。

然后开发主管用了 4 分钟修代码并上线。结果故障依旧!!

开发经理:你们都闪开,我只需要 1 分钟。然后开发经理真的 1 分钟修改代码并上线。结果故障依旧!!!(好吧,到这里连小编都已经看不下去了)

老板:谁能快速的恢复这个故障,我们已经故障整整 13 分钟了!

这个时候运维甲奋力的挤进人群:我们有秒级回滚脚本,所有节点回滚上一个版本并启动不到 1 分钟。

结果,1 分钟后,故障恢复了。

篇幅问题,这个故障就到这里。我想无论你是老板、经理、开发、测试、运维都应该已经明白了,不做过多的解释了。

2.故障复盘

每一次发生故障后,运维负责人都需要牵头进行故障的复盘。开发、测试、运维要一起审查这次故障,搞明白是哪里出了问题,我们应该怎么避免这类故障的再次发生。

俗话说:故障是我们最好的老师。不过这个老师大家都不会喜欢。当然还需要我们详细做好故障的记录。

3.问题管理

故障复盘的目的和问题管理是相同的。ITIL 的服务运营中,问题管理流程的目标是预防问题的产生及由此引发的故障,消除重复出现的故障,并对不能预防的故障尽量降低其对业务的影响。

所以,我们可以在故障复盘的时候,要把这个故障转化为问题管理,全面分析故障的原因,务必彻底解决,而且每项工作一定要落实到具体的负责人。

转载请注明:安全专题


Selinux 中国 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明原文链接:艾玛,全网故障?!我只是插了一根网线!
喜欢 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址