微信邦 发表于 2015-1-25 09:21:12

挖掘故障中的金矿----记一次故障的详细分析



小编:自从小编潜心研究完架构师的四种兵器之后,小编愈发觉得扎实的网络运维经验是架构师的基础,特别需要故障的处理经验,小编上周处理完一个设备重启的故障,心里总觉得少点什么,Timo同学告诉我其实还需要有一个复盘分析的过程,这样可以更好的积累故障处理经验,从表面问题看到内在原因。顿时豁然开朗,经验不敢独享,特别开心的邀请了Timo同学和大家一起分享一起案例,如何找寻故障中的金矿。
http://mmbiz.qpic.cn/mmbiz/iamZnEnc9u9rcvaFVn0axYI3eSsr9esbtgD3qaeYs8iaRdxUHTcGF0zbSrjicegYRLp3vaDV4JEuEzKia6Qn6zQ4iaQ/0对于网络运营来说,故障是金。我们可以对一次次故障进行深度挖掘,不放过任何蛛丝马迹,找出运营中的不足来相应提升维护水平。下面就以一个故障案例来聊聊这方面的故事。

背景在10月份网络上一台配备了主备路由引擎的设备发生了路由引擎重启。由于网络架构冗余,在重启期间,业务流量切换到配对设备上;重启完毕后,设备重新承载流量。如果大家不留意的话,将可能有问题的路由引擎更换掉,整个事情可能就此结束。但我们按照ITIL的问题管理思路来深挖这个故障,还是会发现有不少问题。

初步分析首先是要确定路由引擎重启的原因。经过厂家定位为该设备所采用的同系列路由引擎在极少数情况下,某个软件进程会产生异常,导致内核异常,由路由器内部运行的监控程序(watchdog)监控到失败从而触发了路由引擎的重启。后续需要通过升级软件版本来规避这个问题。处理到这里,表层的问题似乎得到了定位,后续的解决办法也明确了。是否运营工作就此结束了呢?其实未必!本案例中,我们在后续的其他case的排查中,又陆续发现了重启后出现了两个不易觉察的异常。一个是配置异常。设备路由引擎重启后,虽然设备重新承载了流量,业务没有报障,但发现本次路由引擎采用了一个4月份的旧配置!而我们每次修改配置都有将配置写入到设备存储介质中,按道理不应该采用一个这么旧的配置。另外一个是软件版本异常。两个路由引擎使用了不同的软件版本,而10月份重启之前该设备的两个引擎软件版本都是正常的。
深入分析首先来分析设备配置异常。如下是该路由器的一个简单示意图,有一主一备的路由引擎。在主引擎上修改配置时,由主引擎同步给备引擎。10月份重启之前路由引擎1是主引擎;重启之后,路由引擎2是主引擎。
http://mmbiz.qpic.cn/mmbiz/iamZnEnc9u9rcvaFVn0axYI3eSsr9esbt41vK820TTHGsKK9w2W26dUiaBawyytiblhaAeiciaTmYqIOlCKXzb2EfQQ/0该类型设备在路由引擎硬盘和闪存卡都存储了软件版本,分别称为DS,FS(D代表硬盘,F代表闪存,S代表软件);同时也都存储有配置,分别称为DC,FC(C代表配置)。为便于叙述,D1S代表路由引擎1的硬盘软件,F2C代表路由引擎2的闪存配置,依次类推。在正常情况下,路由引擎启动使用的是FS和FC,每次配置变更时,对FC进行同步。该设备除了本次10月份的重启外,在4月份的时候,路由引擎2还出现过重启。但该次引擎2没有从闪存启动而是从硬盘启动,并在此之后是由D2C与引擎1进行配置同步,也就意味着此后F2C停留在了4月份!这次10月份故障,首先是引擎2进行了重启,这次引擎2从闪存启动(而之前是从硬盘启动的),使用F2C,从而取得的是4月份的配置。同时由于处于无响应状态,引擎1稍后也进行了重启。引擎2成为新的主用引擎,导致整个设备当前使用了一个4月份的旧配置。从这一点出发,可以发现我们对4月份引擎2的重启虽然纳入了监控,但没有发现其是从硬盘上重启的,需要加强该类型监控和相应的处理。另外我们在讨论时也觉得有必要建议厂家无论从什么介质进行启动,都应该对所有介质(硬盘和闪存卡)里的配置文件进行同步。后来经过厂家确认是可以有一个命令开关来实现该想法,但有一些限制,比如第一次配置,需要重启设备才生效;在后续的升级过程中需要临时取消该命令等。
再来看软件版本的异常。经过对之前的记录进行分析,是该设备入网之前做了一次软件升级,但没有做存储介质同步的snapshot动作,从而导致了本次软件版本的异常。此次故障后,对该情况同步到全员,确保升级后执行存储介质同步操作,同时还组织进行了一次现网设备的巡检,将不同步的设备进行了同步。

后记从上面一个简单的故障可以看到,每个故障可能都隐藏着一些不易察觉的潜在隐患,都值得我们深入研究,挖掘出潜藏在故障背后的“金矿”,从而使得“坏事变好事”!http://mmbiz.qpic.cn/mmbiz/iamZnEnc9u9rcvaFVn0axYI3eSsr9esbtsFYY221kn7evgkwIb0tyTUkSPhwdrRbQlmOylMGVicVmbfohy5CZq7Q/0


页: [1]
查看完整版本: 挖掘故障中的金矿----记一次故障的详细分析