直面故障，我们该怎么做？

This article has been published on ‘Network Administrator World’ in 2007, copyrights belong to ‘Network Administrator World’.
It was firstly posted on 51CTO blog; no transmission, re-publication, or printing is allowed without explicit authorization of the author.

本文已与2007年刊登在《网管员世界》，版权归《网管员世界》所有。网络首发51CTO博客，转载请务必注明出处并告知本人。

直面故障，我 们 该怎么做 ？

刘志勇

 

作为一个网络管理员，唯一高兴的是完成最后一个任务。这就是这个职业的魅力和生命之所在。以前我们已经许多 次 精疲力尽，然后放弃。但是，我将在本文尽可能帮助广大网络管理员降低现实的困难。

我愿意和读者们共享自己的经验和秘诀 。

 

窥视网管员的工具包

 

真正的硬件工具

每个网管员由于各自实际情况不同，随身携带的真正的硬件工具也未必相同。我的硬件工具包包括：螺丝刀、网卡、牙医镜和微型手电筒、线缆测试仪、录音设备等东西。下面我讲一下这些工具都干什么用。

螺丝刀： 这个工具毋庸多言，就是拆开机箱用的。但有些服务器，比如早期的 Compaq 服务器（现在很少见了，说实话我也几乎没有见到过），这个螺丝刀就必须是 Compaq(Toex) 螺丝刀，其末端是星形的，普通的十字螺丝刀是不能使用的。

网卡： 用于在工作站或服务器上修复常见的问题，有时候可以 用来 确认原来的网卡是否有问题。

牙医镜和微型手电筒： 这是个组合工具，可以让我在紧急时很容易看到组件的反面和主板。

线缆测试仪： 用于网络布线的故障和测试定位，如果线缆测试仪很高级，可对线缆进行周期性检测，确保布线系统的质量。在评估认证后，将电缆测试仪存储的测试结果复制到计算机上并打印出来，作为网络布线基准文档。

录音设备： 相信读者看到这设备肯定惊讶得下巴都掉了 …… 其实，我也是从 历次的 教训中获取的 经验 。还记得有多少次在一个复杂的故障检修过程中一次又一次执行相同的步骤和操作吗？就好比在家中丢失了东西以后在已经找过的地方反复搜寻， 这 合理吗？我是从第一分钟起，将我所采用的每一个步骤口述到录音设备中，这种记录能使我回顾所采用的方法，并决定是否还要遵循检修的路径以及结果的本质。我之所以采用口述的方式，而不是用纸笔来记录故障检修的过程就是因为：厌倦！人们往往可以手写记录下故障检修过程的前面几个步骤，或者前面几个小时所采用的步骤，但会随着时间的推移，厌倦 会 导致这种工作的中断：所采用的步骤没有记录或者是跳过了记录。而口述是一种相对比较轻松的记录故障检修过程的工作，能记录下自始至终的每一步。

其他的工具，要视乎你的工具包是否还有额外的空间，以及你实际的情况，比如 ， 昂贵的 FLUKE 网络测试仪器，并不是每个 人 都会配备的。

 

软件工具包

网管员可以根据自己的习惯、爱好等选择适合自己的软件工具包，软件工具包的形式可以是 LiveCD 或者集成了维修工具的 Windows P E 启动光盘，也可以是别的光盘，我用的 Windows P E 启动光盘是深山红叶工具光盘，很好用，网络上有很多与之相类似的工具光盘。 Live Cd 我选择的是 Knoppix 汉化版， Live CD 的选择有很多，比如 Trinity Rescue Kit 等等，都可以作为急救用的 Live CD 。

现在闪存容量越来越大了， 加之 现在的新电脑都支持从闪存启动 系统 ，我们完全可以制作成 Live USB ，在一定程度上比 Live C D 更为灵活。 即使不做 Live USB ， 也可以把常用的工具拷贝到闪存内，以备急需。 关于这方面可以参考我在 2007 年 5 期《电脑自做》第 96-101 页刊登的《闪存扩展 随心而动》文章。

还有一些驱动软盘，虽说现在软盘和软驱近乎绝迹了，但有些场合还是需要的，比如 RAID 驱动程序等等。

This article was published on Network Administrator World in 2007, and the copyrights belong to Network Administrator World. The article was first posted on 51CTO blog, no transmission, re-publication, printing allowed unless with explicit authorization of author.

本文已与2007年刊登在《网管员世界》，版权归《网管员世界》所有。网络首发51CTO博客，转载请务必注明出处并告知本人。

 

杂项

其他还有一些乱七八糟的东西，我带的就有小门垫、工作服、套衫、休闲鞋、巧克力什么的。很惊讶吧？嗯。我带的小门垫的真实作用是在拥挤的服务器房绕电缆的时候，我跪在上面用来保护我的膝盖。而不是跪下向客户和管理人员请罪，哈哈！

很多公司对员工的着装有很严格的要求，必须穿正式的服装，不能穿休闲的，那么在脏乱的库房和机房里，这一身正式的、严肃的服装是不是很让你为难？我带一套工作服、套衫、休闲鞋就是为了应付这种窘境的。

巧克力是干什么的？不怕各位笑话，我这人有时候有点胆怯，面对未知的故障的时候有时会感到恐惧，这时候吃点巧克力能提高血糖帮助消除恐惧感。

 

笔记本

从一定意义来说，它可以说是工作日志 。 你可以用纸媒介的本子来记笔记，也可以用电子版形式的，只要能达到目的就好，我用的是电子文档。笔记本对于我来说，它的作用就是 告诉我 ：出 现 问题时，哪些发生了变化。

当出现一个新的问题时，所要问的第一件事 往往 就是出现问题之前，是否有什么变化。

任何网络操作系统都是一个有问题的系统，有时因为一些不能解释的原因，甚至大部分无害的变化都有可能变得一团糟。如果你的笔记本，记录了每个服务器、每个设备所有变化的详细日志 ， 能节省你用在故障检修上的数 个 小时。作为我来讲，我有每个服务器单独的 Excel 电子表格，记录了安装新软件包、安排重新启动与否、添加新驱动器或者别的软件等等，还有时间、日期、服务器每次变化的属性。

如果在本周对服务器所做的更改，在下周引起了问题，那么你的笔记本就 将 发挥非常大的作用。

笔记本对于任何故障的成功解决非常重要。一个人对管理机器明晰，而他的同事却什么 都 不懂，这就毫无意义了。我认为，这是一种非常危险的处境，特别是问题中的任务对网络的安全至关重要。如果一旦这个人发生意外，其余的人该怎么办呢？

从实践经验来看，随着新过程的发展将其文档化的做法是值得鼓励的。我就有过这种经历：曾经完美处理过一些事情，但仅仅过了一个月之后就遗忘了！这时候我多么希望自己以前就记录到笔记本上啊！ 这种情况经常会发生。

实际上，根据我的经验，当出现问题时，不论是打印驱动程序被破坏，还是客户端连不上网络，都应该记笔记。十有八九在开始进行之前，当处理问题之后，回到办公室就会忘记自己做了什么。

想象一下，如果处理问题时和不断升级必须有一段停机时间，回想使用的规程可能没有归档，会怎么样呢？

笔记的归档也很重要。虽然归档的内容有一些可能会过时了，比如 Windows NT ，但无论什么方法，都要保存起来。一些详细任务可能再次适用于当前的网络。另外，当按照新规程部署或者进行 Beta 测试时，归档就更为重要。如果坚持这种做法，这样任何人走入服务器机房都可以按照归档的笔记执行任务，这对网络管理工作不是很好吗？

 

This article was published on Network Administrator World in 2007, and the copyrights belong to Network Administrator World. The article was first posted on 51CTO blog, no transmission, re-publication, printing allowed unless with explicit authorization of author.

本文已与2007年刊登在《网管员世界》，版权归《网管员世界》所有。网络首发51CTO博客，转载请务必注明出处并告知本人。

故障检修秘诀

Hello ，现在我们终于到达了文章最重要的部分。

 

我的心得

记得 MCSE 曾经说过，超过 58% 的故障检修成功是基于经验的，无论这种经验的知识来源于一般计算机系统知识还是所面对的具体问题的知识。剩下的故障检修成功因素包括运气，研究工作和你原本的解决问题的能力。

我认为，重要的是：提高你的故障检修技巧是长久之计，而不是得到后就可以忘记的结果。

故障检修技巧虽然主要是通过积累经验来提高，但实际上，也可以通过阅读（文章、博客和论坛等）、培训和其他的方式获得。

如果你缺乏使用 Linux 服务器的经验，这并不意味着在解决问题时你就就一定缺少经验，即使你具有丰富的技艺也可能只在特定的故障检修情形中看到其他人会忽视的方面。 Nike 有一句广告词，我很赞赏，这就是： Just do it! 就是说，不要让你的经验阻碍你获取更多的经验！

 

故障检修的步骤

这里列出的步骤，是用于解决所有问题的“基础”，是指导解决问题的基础。

故障检修的步骤有：识别问题、诊断故障、找出解决方案并实施、确认故障是否解决、记录解决方案。

识别问题：就是鉴别问题是属于硬件问题还是故障问题。

诊断故障：区分故障的症状和起因。确认系统故障是否由于底层的、基本的因素所致；确定这样的症状，是否有利于解决其起因。

找出解决方案并实施：毫无疑问，这个步骤通常是反复的，一次又一次的过程。

确认故障是否解决：上个步骤的解决方案一般需要在不同条件下测试多次。

记录解决方案：有时候，我经常成功的实践了一个很好的解决方案，但是忘记了这是在以后遇到同样的问题时更好解决问题的一个关键。这种情况下，就不得不重新学习这个方案，很明显，花费几分钟的时间记录在排除故障过程中的每一个解决方案很快就能使你获得巨大的意外收获。

 

总结

微软公司提出过一个故障检修方法论：谓之 D.E.T.E.C.T 。这是由一组微软微软技术支持工程师创立的方法，为我们提供了一个策略。实际上，这些步骤是放之四海皆准的，无论是交换机故障，还是 Windows 服务器故障，抑或是 Linux 服务器故障，都适用。

D.E.T.E.C.T 是：

D Discover 发现问题

在用户层次上与用户交谈，试着了解他们使用的软件（如果可能的话，包括发布的版本）以及他们的硬件是否在硬件兼容性列表内。问题表现出的症状是什么。

E E xplore 探索界限

是否能够鉴别自从上一次报告系统正常以来都发生了那些变化？能否鉴别问题发生时运行的是什么软件吗？

T T rack 跟踪可能的方法

你可以从处理这些故障中学习并通过跟踪所采取的步骤，避免陈旧的、效率低下的尝试——错误的方法。

E E xecute 实施方法

撇开管理问题，以便在第一个方案的尝试失败时不会受到其它部门的干扰。若方案 A 失败就应考虑方案 B 。不要忘记在执行解决问题的任务之前备份重要的系统和应用程序。

C C heck 检验成功

T 总结

不管是什么样的故障排除方法，本质上所有的方法都是遵从一个基本的模式：

发送者——→接受者

输入——处理——输出模式

按照微软 D.E.T.E.C.T 方法论，进行故障查找明显的是成功解决系统问题的第一步。

 

故障检修的定义

方法论

相信很多网管员都会叹息过：如果能够恢复这一切就好了。

在很大程度中，故障检修是一种方法论。木工有一句话可以引用在这里：两次测量，一次切断。网管员在任何情况下都应三思而后行。

遵从故障排除的黄金规则可以减少你的痛苦：“一次只改变一个变量。”一次改变一个变量，然后进行成功或失败的测试，这样就能有效的证明我们排除故障工作工作的结果。这就是方法论的精髓。

我再次强调：在排除故障时，一次一个变量并进行测试。相信我！

 

一小时原则

经验表明，缺乏经验的网管员，尤其是刚入行的，更容易误入歧途。在查找问题时视野狭窄或者错过了即时的观察就有可能误入歧途。狭窄的视野是一个陷阱，没有考虑到外部因素可能会产生问题。外部因素有时也会导致灾难。在我刚入行的时候，总是从主管的角度来观察网络环境，但实际上，总有一些在我控制之外的因素也会对我们产生影响。

在任何一种情况下，基本上应该将排除故障恢复状态寻求帮助的工作时间限制为一小时。我比较倾向的方法是只进行一个小时解决服务器等问题的工作，如果不能解决问题或者保证合理的结束，就给技术支持小组打电话或者与这个领域的同行进行探讨。一定要充分利用在这个领域中的同行专家资源。

在一些技术论坛，比如网管员世界论坛、 51CTO 论坛可以找到该领域的同行，也可加入他们的 QQ 群，提供和接受解决所遇到问题的建议。根据一小时原则，当你已经花费了一个小时试图解决问题时，立刻去 QQ 群或者论坛呼叫同行。

 

故障时间价值的计算

故障时间的价值，也是在故障检修时要考虑的一个因素。

但是根据我的实际经验，很多工作人员可能会以系统故障为借口停止工作并且可能回家，请问，在办公室中，你看到过员工利用计算机故障时间来回复耽误的电话吗？没有。很多员工可能只是说计算机系统崩溃了而无法工作。

我觉得故障时间价值的计算，不是三言两语能够说明白的，总之，系统故障时间的代价决定了你解决问题的方法，系统故障时间是非常昂贵的，即时在一个很小的企业中，你也可以估算出系统故障时间的代价究竟值多少人民币。

This article was published on Network Administrator World in 2007, and the copyrights belong to Network Administrator World. The article was first posted on 51CTO blog, no transmission, re-publication, printing allowed unless with explicit authorization of author.

本文已与2007年刊登在《网管员世界》，版权归《网管员世界》所有。网络首发51CTO博客，转载请务必注明出处并告知本人。

 

故障检修图

我写书或者写技术文章，总是从一个提纲或者脑图开始。如果故障检修也像这样，那么会更好的进行，并且更加有效。我的经验是，在白板上创建故障检修路线图。每次当我遇到困难的时候，离开机房回到自己的办公室——这往往是解决问题的灵丹妙药——可以静下心来，用清晰的和平衡的头脑进行思考。

通过在白板上创建故障检修图，你可以在工作中包含很多业务管理者。很多业务管理者都熟悉在会议室中反映情况，那里是很舒适的地方。通过在问题的解决方案中包括业务上的管理者，我们不仅能够获得新鲜的血液和新鲜的见解，而且还能够在技术和业务团体之间树立正面的管理。通过这样的手段，可以向他们宣传解决方案，而且更重要的是，可以迫使他们接受我们的方案。无数的研究以及你自己的工作经验已经说明有领导们的支持时，成功的几率会更高。

 

学习曲线分析

实际上就是分析解决故障是否在自己的能力范围之内。这里提供一个表格：

问题的本质	技能	学习曲线	建议解决方案
简单	高	低级	自行解决
经常发生，不困难	中	中级	在经过一些学习和阴暗解答之后解决问题好处包括能够很好的利用学习时间。因为这种类型的问题频繁发生，一旦进行学习并找到了解决方案，那么下一次解决问题就很容易。
频繁发生，问题介于简单和困难之间	低到中	中级到高级	这时与技术顾问或专家组成团队就很有意义。可以让专家展示解决方案，以便在将来能够独立的解决问题。
在寿命期间只发生一次，非常困难	不存在	很高级	交给别人做。保留一个专家来解决问题，并努力进行解释。

这个表格展现了一个决策模式，可以用于解决问题和利用外部专家的技能时。

对于前两种情况，可能要很好的利用你的时间来解决问题。对于后两个情况而言，明显的需要帮助才能将系统故障时间和公司与相关问题的损失减少到最小的程度。

在早期排除故障的工作中，了解你要解决的问题的本质，并确定你是否能够独立解决问题，还是需要其他的帮助以加强工作。

 

整体衡量：过多的检修，过少的时间

工作的成功是以整体衡量的，不要陷入故障检修的黑洞中而没有很好的完成其他工作。

实际上，如果给予足够的时间，很多网管员都能够解决问题。但是，时间对于我们每一个人都有限制。你会发现并没有足够的时间来完成想要做的任何事情。你有没有发现过这么一个情况：从星期一开始查找一个故障，当抬头看时间时却发现已经是星期五下午了？是否注意到了在我们埋头查找问题时，其他的工作已经堆积如山？

即时你有很高的排除网络故障的技能，但也可能被提升并领导 IT 部门，你是否明白，你的角色已经改变，你应该将故障检修的任务委派给一个下属。因为故障检修的时间问题中包含有核心能力。

 

结交更多的同行朋友

很多时间，都是花费在争论问题究竟是与硬件有关还是与软件有关。

如果你在一方面很强，例如软件方面，那么正在查找没有解决方案的软硬件问题时，而解决方案很可能就从你所薄弱的一方出现。就是说，如果从有优势的一方已在上市解决问题，往往是另一方导致了我们的失败。我的经验告诉我，不止有一个坏掉的网卡导致了软件相关的网络问题！

所以，我的建议是，结交更多的同行朋友！这是查找硬件和软件相关问题时的一个技巧。

读者可以在网管员世界论坛找到相同领域的同行。

 

回顾上世纪 90 年代，这是怎样的一个漫长、离奇和有趣的旅程啊！从 Netware 的升起和陨落到 Windows Server 统治的出现，再到 Linux 的崛起，这个过程是相当快的。但是有些事情会一直保持下去，包括对于顶尖的排除故障技能的需要。随着信息化的进展，对于这些技能的需要、寻找和使用更加明显，因为，每一个网管员不再被看作是后台的技术人员，事实上，现在网管员已经引起了高层的重视，因为故障事件是令人难以置信的代价！即使是非技术的高管也能够理解这点。随着信息化更大的进展，信息化承担重要任务的、企业范围内的应用，更多的前台管理人员需要网管员卓越的排除故障技能来保证这些东西正常运行。

祝你们好运！

This article was published on Network Administrator World in 2007, and the copyrights belong to Network Administrator World. The article was first posted on 51CTO blog, no transmission, re-publication, printing allowed unless with explicit authorization of author.

本文已与2007年刊登在《网管员世界》，版权归《网管员世界》所有。网络首发51CTO博客，转载请务必注明出处并告知本人。

刘志勇

二〇〇七年八月于天津