接着排查故障

 

第二天网管们一来，就被我支到了四楼排查故障。

刚开始，他们把四楼的网络全部断开，我这才启动四楼的端口（因为这样才不会影响其他人），然后让他们一个端口一个端口插上。很快找到了下一级有问题的交换机。不幸的是，这个交换机并不是末级交换机。在这个被我们怀疑有问题的交换机上竟然下联了3个交换机覆盖了大厅的绝大部分区域，问题远不只这些，这个交换机还连接了十多个座位的网线。没有办法，只好一个一个全部拔下来。在我的指挥下，网管将网线4根4根地插上。我想，这可能算是我指挥地一个失误，但是造成这个失误也是有些原因。这个失误就在于我急于排查错误，没有对网线分类对待，没有考虑最高效率原则，直观地认为能够通过这种无类别地分组就可以轻松地定位交换机地故障。这个失误也造成了网管们地错误判断。当第二组线插上以后，问题就出现了，但是，将那些线拔下来，问题并没有恢复。这个时候，网管们怀疑交换机本身有故障。我同意了这个观点。那就更换交换机吧。恰巧，办公室里没有交换机了，于是我找了台性能看上去不错地hub，选中它，一个原因是因为它有24个口，可以满足端口数量地要求，另一个原因，就是因为它上面有很多指示灯，我很喜欢这种指示灯（我其实很喜欢看见电子设备上那些一闪一闪地指示灯），所以我选中了它，没想到后来这些指示灯帮了我们的大忙。

 

网管拿着hub上去好一会，却不见好转。我拿着自己的笔记本就上去了。当我上去的时候，网管杨野告诉我，他正已经将网线分好了类，但是，在没有连接座位网线的情况下，只连接下级交换机的网线，hub的指示灯就告诉它使用率超过100%。他怀疑hub的性能有问题。我并不这么认为。我让他一根一根的插，当插上边上一排座位的时候hub就出现了100％的使用率，笔记本上的ping命令显示网络中断。我们拔下最后插上去的网线，故障并没有立即消失。难道有其他的节点和它呼应，难道它会激活另外一个有故障的区域？我稍微迟疑了一下，没想到网络竟然好转，我开始意识到问题可能不是环回导致的，故障点在最后那个点是没有错的，它必须在切断网络后一段时间才会恢复。我试验了一下，果然和我猜测的一样。那么是不是那个交换机坏了呢？在这个区域内有很多的服务器，是不是这些服务器造成的呢？网管开始整理网线，看看是否是网线环回或短路造成的。结果证明这些网线连接的没有问题。

 

我先要求网管将那个区域的交换机在空载的时候接入上级那个hub，没有问题，这说明不是交换机本身个故障。

 

接入除服务器以外所有的座位上的网线，没有问题，说明这些座位上的计算机没有问题。

 

一个一个地接入服务器，当我们接入倒数第二台服务器时，问题就出现了。显然，这个服务器有问题，问题总算找到了。

 

这里，我总结了几点经验：

1、在排错过程中对排查的对象进行分类，是在任何时候都应该遵循的一条法则。通过对排查对象分类，分析每种对象的权重，计算出最高效率的算法远比无差别的排查效率要高。

 

2、有些故障点在移除交换机后，它造成的影响不会立即消失，你可以等一会，或者重启交换机来重置状态。

 

3、利用善于利用观测手段，在这次排查中，那个hub的指示灯＆笔记本的ping命令给我们很多的帮助。