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

微信邦

小编：自从小编潜心研究完架构师的四种兵器之后，小编愈发觉得扎实的网络运维经验是架构师的基础，特别需要故障的处理经验，小编上周处理完一个设备重启的故障，心里总觉得少点什么，Timo同学告诉我其实还需要有一个复盘分析的过程，这样可以更好的积累故障处理经验，从表面问题看到内在原因。顿时豁然开朗，经验不敢独享，特别开心的邀请了Timo同学和大家一起分享一起案例，如何找寻故障中的金矿。

对于网络运营来说，故障是金。我们可以对一次次故障进行深度挖掘，不放过任何蛛丝马迹，找出运营中的不足来相应提升维护水平。下面就以一个故障案例来聊聊这方面的故事。

背景

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

初步分析

首先是要确定路由引擎重启的原因。经过厂家定位为该设备所采用的同系列路由引擎在极少数情况下，某个软件进程会产生异常，导致内核异常，由路由器内部运行的监控程序（watchdog）监控到失败从而触发了路由引擎的重启。后续需要通过升级软件版本来规避这个问题。

处理到这里，表层的问题似乎得到了定位，后续的解决办法也明确了。是否运营工作就此结束了呢？其实未必！本案例中，我们在后续的其他case的排查中，又陆续发现了重启后出现了两个不易觉察的异常。一个是配置异常。设备路由引擎重启后，虽然设备重新承载了流量，业务没有报障，但发现本次路由引擎采用了一个4月份的旧配置！而我们每次修改配置都有将配置写入到设备存储介质中，按道理不应该采用一个这么旧的配置。另外一个是软件版本异常。两个路由引擎使用了不同的软件版本，而10月份重启之前该设备的两个引擎软件版本都是正常的。

深入分析

首先来分析设备配置异常。如下是该路由器的一个简单示意图，有一主一备的路由引擎。在主引擎上修改配置时，由主引擎同步给备引擎。10月份重启之前路由引擎1是主引擎；重启之后，路由引擎2是主引擎。

该类型设备在路由引擎硬盘和闪存卡都存储了软件版本，分别称为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动作，从而导致了本次软件版本的异常。此次故障后，对该情况同步到全员，确保升级后执行存储介质同步操作，同时还组织进行了一次现网设备的巡检，将不同步的设备进行了同步。

后记

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