收集有关的情况并对问题进行分析

            主要包括对设备进行观察，设法了解问题究竟存在什么位置。可以通过查看路由器的接口和进程命令，查看内存、缓存和CPU的使用情况等等。在查看过程中，应记录发现的情况，以便评估存在问题的原因。如遇到间歇性失去连接的问题，注意查看该接口复位了多少次。如果问题与访问列表相关，就需要查看访问列表是如何设置的，与现有文档的注释进行比较，判断是否一致。如现有的设置与文档不一致，应审查更新文档的策略。在尽可能收集到各种情况后，即可转入对问题原因的分析工作。

            分析产生问题的原因就是要确定这个问题本身有什么表现，谁受到了这个问题的影响。如果我们不知道这个情况，就需要倒退一个或两个步骤，重新思考这个问题。如果收集到正确的信息，那么在解决问题模型中，这是最容易执行的步骤之一。知道谁受到了问题的影响，这个问题有何表现，问题在何时发生，以及问题发生在何处。剩下的唯一问题就是这个问题为何会发生。当我们对OSI模型有一个透彻的了解时，解决这个问题对故障诊断者来说就变得易如反掌了。因此要求我们对OSI模型的每一层协议功能要非常熟悉，才能从中获得重要的线索，以确定问题为何会发生。 当您认为问题的原因已经找到后，应该再花一点时间来确定其他还有什么原因导致问题的产生。您应该避免只找出单个原因。只有找到确定的原因越多，您解决问题的可能性就越大。因此要尽量找出可能的故障原因，按降序列出导致故障的可能原因，并从中找出最有可能的故障原因。

            设计解决问题计划只有当确定了导致问题产生的最有可能的原因时，才能制定一个操作计划。包括为了解决问题而计划使用的操作步骤。在确定操作步骤时。应尽量做到详细；这个计划越详细，按照这个计划执行的可能性就越大。一旦制定好计划，就要按步骤实施这个计划。

            实施解决问题计划当在实施操作计划时，以特别注意，每次只能作一个修改。如果修改后问题解决，那么应该将修改的结果进行分析并记入文档。如果修改没有成功，应该立即撤消这个修改。重要的是要按照制定的计划来进行操作。因为在实施计划中，有时由于某一步不行，很容易尝试新的方法。这样做的危害是很快就失去对原计划的跟踪线索，结果往往使情况变得更加槽糕。一旦发现原计划不可行，正确的方法是应该重新设计计划，然后实施新的计划。 另外，在实施操作计划时，应特别注意安全程序的执行。安全性是我们最担心的事情。不要或者尽量少开放网络，在解决问题时，也应该尽可能缩短放松安全性的时间。前者可以阻止不太精明黑客突破网络的企图，后者可以减少黑客在在网络安全性放松时攻击网络的可能性。 评估操作计划产生的结果 观察结果最简单的方法是用第一步中获得的数据来测试。问题的表现或者某些表现是否仍然存在呢？如在第一步中简明说明了存在的问题，那么就可以较容易地测定问题地表现是否存在。如果问题的某些表现已经解决，但其他的表现仍然存在，那么将解决方案记入文档，然后转入下一个操作步骤。 间歇性问题的测试并不是那么容易进行。有时要等到发生另一个故障时才能进行测试。在这种情况时，在最终确定问题之前，必须把对系统的修改记入文档，这是非常重要的。

            重复操作过程在完美无缺的环境中，根本不需要重复上面的操作过程，因为我们对问题的分析肯定能够指明存在的一个问题，也是唯一的问题。但在实际工作中我们很少能够做到完美无缺。当操作计划不能产生预期的结果时，首先应该撤消试图解决问题时所做的所有修改。如果保留这些修改，可能导致出现一些遗留问题。 下一步是搞清什么地方分析失败了。通过确定问题的性质来重新启动这个操作过程，这是非常重要的。对问题进行分析时，要对自己提出的所有假设多问几个为什么。重新确定问题的性质，当第二次设法解决问题时，要花费更多的时间去考察问题的细节，深入到问题的内部去看一看。如第一次解决问题时有些情况没有注意到，应该确保第二次解决问题时不要犯与第一次同样的错误。