【鹅厂网事】挖掘故障中的金矿----记一次故障的详细分析

“鹅厂网事”由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营，我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息，同时分享腾讯在网络与服务器领域，规划、运营、研发、服务等层面的实战干货，期待与您的共同成长。

网络平台部以构建敏捷、弹性、低成本的业界领先海量互联网云计算服务平台，为支撑腾讯公司业务持续发展，为业务建立竞争优势、构建行业健康生态而持续贡献价值！

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

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

我想提问

本文有任何问题想与作者进行讨论，欢迎在“鹅厂网事”的“我谈”模块进行留言，会有文章的作者为您回答哦。

欢迎关注公众帐号“鹅厂网事”，我们给你提供最新的行业动态信息、腾讯网络与服务器最接地气的干货分享，还有一大波互动交流板块和有奖活动正在筹备当中，需要您的热情参与哦，敬请期待！

注1：凡注明来自“鹅厂网事”的文字和图片等作品，版权均属于“深圳市腾讯计算机系统有限公司”所有，未经官方授权，不得使用，如有违反，一经查实，将保留追究权利；

注2：本文图片部分来至互联网，如涉及相关版权问题，请联系tracyyun@tencent.com