2.1 故障检测与排除方法及流程
CCNP TSHOOT 300-135学习指南
常规的故障检测与排除进程通常都包括以下任务（子进程）。
1．定义故障。
2．收集信息。
3．分析信息。
4．排除潜在的故障原因。
5．提出推断（推断最可能的故障原因）。
6．测试和验证所推断故障的正确性。
7．解决故障并记录排障过程。
可以将网络故障检测与排除进程归结为一些基本的子进程（如前面的步骤列表所示）。这些子进程在本质上并没有绝对的先后之分，很多时候需要反复执行这些子进程，直至最终解决故障为止。图2-1以流程图的方式解释了在结构化故障检测与排除进程中实施这些任务/子进程的次序。虽然故障检测与排除方法可以帮助大家以一种结构化方式来执行这些子进程，但世上并不存在任何故障检测与排除的良药秘方，每个故障都不一样，根本不可能创建一份能够解决所有故障问题的通用脚本。
)
图2-1 结构化故障检测与排除方法流程图
故障检测与排除是一门要求具备相关知识和经验的技巧。通过在实践中不断应用这些故障检测与排除方法，大家能够更有效地为特定故障选择正确的故障检测与排除方法、收集相关信息，并能更快更高效地分析故障。获得足够多的排障经验之后，就可以省略某些步骤，更多地采用不假思索法来更快更高效地解决故障。无论如何，为了成功实施故障检测与排除工作，必须弄清楚以下问题。
每个基本故障检测与排除子进程或阶段的实施计划是什么？
在每个基本子进程中具体需要做什么？
需要做出什么决策？
需要哪些支持或哪些资源？
需要进行哪些沟通？
如何正确分配职责？
虽然这些问题对每个企业组织来说各不相同，但是通过规划、文档化和实施故障检测与排除流程，就一定能改善故障检测与排除进程的一致性和有效性。
2.1.1 定义故障
虽然所有的故障检测与排除流程都起始于故障定义，但真正触发故障检测与排除流程的却是用户遇到故障并将故障报告给网络支持团队。从图2-2可以看出，故障报告（由用户完成）触发了故障检测与排除流程，接下来就要验证和定义故障（由网络支持团队完成）。除非企业拥有严格的故障报告制度，否则用户报告的故障大都含糊不清甚至让人误解。大家经常会接到类似的故障报告：“访问企业内联网的某个站点时，网页显示我无权访问”、“邮件服务器不工作了”或“无法归档我的费用报告”，等等。大家可能已经注意到了，第二个故障报告完全是用户自己的推断，故障现象可能仅仅是他无法收发电子邮件。为了防止排障人员在故障检测与排除阶段基于这类错误的假设或报告而浪费大量时间和精力，故障检测与排除流程的第一步就是要验证和定义故障。也就是说，首先要确认故障问题，然后再由排障人员（即网络支持工程师而不是用户）清晰地定义故障。一个好的故障定义必须包括故障发生时间、最近是否做了配置变更或者升级，以及故障的影响面等信息。知道故障仅影响单个用户（不影响其他用户）还是影响一组用户也是非常有价值的，因为这会影响你的分析（排除潜在故障原因并推断故障原因）以及对故障检测与排除方法的选择。
图2-2 定义故障：网络支持人员必须首先验证并定义故障
好的故障报告必须包含准确的故障现象描述，而不是对故障的理解或结论。虽然从严格意义上来说，故障后果并不是故障描述的一个必要组成部分，但是能够帮助排障人员评估故障的紧急程度。当用户报告“邮件服务器不工作了”的时候，排障人员必须与该用户进行沟通，以确认该用户到底遇到了什么故障，进而有可能将该故障定义为“用户X启动电子邮件客户端后，收到一条错误消息，称客户端无法连接服务器，但该用户仍然可以访问他的网络硬盘并浏览Internet”。
明确定义了故障问题并创建故障工单之后，在开始真正的故障检测与排除进程之前还有一些工作要做，那就是必须确认该故障是否属于自己的职责范围，是否需要上报给其他部门或其他人。例如，假设所报告的故障是“用户Y试图访问企业内联网上的公司通讯录时，收到一条拒绝访问的消息，但是该用户可以访问其他内网网页”。作为网络工程师，由于这些内联网服务器由公司内的其他部门负责管理，因而也无权访问这些服务器。此时必须知道收到用户报告的这类故障报告时该如何处理，必须知道是否需要为这类故障启动故障检测与排除流程或者是否要将这类故障上报给服务器管理部门，必须清楚自己的职责范围，知道将故障提交给其他部门之前自己需要做哪些操作以及如何上报故障。图2-2解释了定义故障之后所要做的故障任务分配工作：要么将故障上报给其他维护支持团队或其他部门，要么就属于网络支持工程师的职责。对于后一种情况来说，接下来的工作就是收集信息。
2.1.2 收集信息
收集信息之前，需要选择初始故障检测与排除方法并制定相应的信息收集计划。作为信息收集计划的一部分，需要确定信息收集进程的对象。换句话说，必须确定需要收集哪些设备、客户端或服务器的信息，需要使用哪些工具来收集这些信息（准备一个工具包）。接下来必须获得这些信息收集对象的访问权限。在很多情况下，访问这些系统是网络支持工程师的职权之一，但某些情况下，可能需要获得那些无法正常访问的系统的信息。此时可能需要将这个问题报告给其他部门或其他人员，或者是获得相应的访问权限，或者由他人负责收集这些信息。如果上报进程很慢以至于影响到故障检测与排除流程的进度，而且该故障很紧急，那么就需要考虑更换其他的故障检测与排除方法。首先要尝试使用那些有权访问（而不用上报给其他部门）的信息收集对象。从图2-3可以看出，根据排障人员是否能够访问和检查这些设备，一种可能是将故障上报给其他网络支持团队或其他部门，另一种可能是实施信息收集和分析步骤。
图2-3 收集信息：缺乏设备访问权限的话，就可能需要将故障问题转交给其他网络支持团队
下面的案例将说明不受控因素对信息收集工作可能产生的影响，最终将迫使排障人员改用其他的故障检测与排除方法。假设当前时间是下午1点，企业的销售经理报告无法在其工作的分支机构办公室收发电子邮件。由于该销售经理必须在下午晚些时候向一个重要的RFP（Request For Proposal，建议请求）发送响应邮件，因而该故障十分紧急。作为排障人员，第一反应可能是使用自顶而下故障检测与排除法，给该销售经理打电话并运行一系列测试操作，但由于该销售经理需要一直开会到下午4:30，因而暂时联系不上。与该销售经理位于同一个分支机构的同事告诉排障人员，虽然销售经理正在开会，但是笔记本电脑在其办公桌上，而且客户需要在下午5点之前收到RFP响应。此时，即便自顶而下故障检测与排除法看起来是最佳选择，但是由于排障人员无法访问该销售经理的笔记本电脑，因而只能等到下午4:30以后才能开始检测与排除该故障。然而将整个故障检测与排除工作集中在30分钟之内将存在很大风险，而且会给排障人员带来很大压力。针对这种情况，最好结合使用自底而上法和跟踪流量路径法来解决该故障。排障人员可以验证该销售经理的笔记本电脑与公司邮件服务器之间是否存在第一层至第三层故障。即使没有发现任何故障，那么也能排除很多潜在故障原因，这样就能大大提高下午4:30以后开始实施自顶而下故障检测与排除法的效率。
2.1.3 分析信息
从各种相关设备收集到足够的信息之后就要理解并分析这些信息。为了正确理解收集到的原始信息（如show命令和debug命令的输出结果，或者是抓取的数据包及设备日志），排障人员必须深入研究这些命令、协议及技术，有时还需要查阅相关网络文档，以正确理解实际网络部署过程中这些信息的真正含义。
在分析收集到的信息时，通常需要确定两件事：网络中发生了什么以及网络中应该发生什么。如果发现了这两者之间的差异，那么就能发现故障根源的相关线索或者至少知道了进一步收集信息的方向。从图2-4可以看出，在理解和分析收集到的各种信息以排除潜在故障原因并找出根本性故障原因时，需要将收集到的信息、网络文档、基线信息以及研究结果和过往经验都作为输入条件，从而排除潜在故障原因并找出真正的故障根源。
图2-4 分析信息：需要综合考虑并融入收集到的信息与现有信息以及知识与经验
排障人员对网络中究竟发生了什么的认识通常建立在对原始数据的理解之上（借助于研究成果和网络文档），但是对底层协议及相关技术的理解程度对于正确认识网络行为来说至关重要。如果对相关故障的协议及技术不是很熟悉，那么建议大家花点时间去研究它们的工作原理。此外，好的网络基线行为数据对信息分析阶段来说也非常关键。如果排障人员知道网络的运行状况以及正常情况下的网络行为，那么就能更快地发现网络的异常状况并从中找出故障线索。当然，过往大量工作经验的重要性也不容小觑。与缺乏经验的网络工程师相比，经验丰富的网络工程师可以在技术研究阶段、理解原始数据阶段以及从大量原始数据中找出有价值的信息分析阶段节省大量时间。
2.1.4 排除潜在故障原因
在分析收集到的信息时，考虑并结合已有的各种信息（如网络基线和文档），能够帮助排除很多潜在故障原因。例如，如果用户能够ping通特定Web服务器，但是却无法浏览其主页，那么就能轻易排除很多潜在故障原因，如物理层、数据链路层和网络层故障或错误配置。从图2-5可以看出，根据收集到信息以及做出的各种假设，可以从所有的潜在故障原因中排除部分故障原因，然后在下一个步骤中评估并验证剩其余的潜在故障原因。
图2-5 排除潜在故障原因：利用收集到的信息和假设推断能够帮助排除部分潜在故障原因
排除潜在故障原因时，必须意识到假设所带来的重大影响。假设可能正确也可能不正确，如果最终发现结论有冲突或者场景无意义，那么就需要收集更多信息并分析这些新信息，进而重新评估之前做出的假设推断。例如，在排查用户无法访问或使用特定服务的时候，如果建立在错误的假设基础上，认为用户在过去能够使用该服务，那么就可能会在信息分析阶段浪费大量时间，而且无法得出合理的结论。
2.1.5 提出推断（推断最可能的故障原因）
排除了潜在故障原因之后，通常还会剩下一些可能的潜在故障原因，必须根据可能性对这些潜在故障原因进行排序，从而根据最可能的潜在故障原因推断根本性故障原因。请注意，对潜在故障原因进行排序时，同样需要用到你的知识、过往经验以及假设。从图2-6可以看出，推断出的最可能的故障原因可能位于你的职权范围之内，也可能不在你的职权范围之内，此时就可能要将该故障工单转交给其他网络支持团队或其他部门。此外，从图2-6还可以看出，确定了最可能的故障原因之后，还可能需要进一步收集相关信息，从而触发新一轮的分析信息、排除潜在故障原因以及提出推断的处理过程。
推断出根本性故障原因之后，就可以进入结构化故障检测与排除进程中的下一个步骤：验证推断。如果发现推断出来的最可能故障原因不是真正的故障原因，那么通常就要将第二最可能的潜在故障原因视为新的故障推断，并再次加以验证。该过程将一直持续下去，直至解决故障问题，或者在没有解决故障问题的情况下遍历了所有潜在故障原因。对于后一种情况来说，就需要收集更多信息，并开始新一轮的故障检测与排除过程。当然，也可以将故障问题上报给更有经验的支持团队，或者咨询外部资源，如咨询公司或Cisco TAC（Technical Assistance Center，技术支持中心）。
如果决定上报故障，那么就需要确定自己是否仍要继续参加该故障的检测与排除进程。请注意，上报故障并不等同于解决故障，必须考虑其他部门或其他人可能需要多长时间才能解决故障以及该故障的紧急程度，遭受故障影响的用户可能无法忍受太长时间等待其他部门来解决该故障。如果自己无法解决故障，但该故障又紧急到无法等待上报流程来解决，那么就可能需要搭建一个临时工作环境，虽然这样并不能从根本上解决该故障，但是却可以缓解用户所遭受的故障影响。
2.1.6 测试和验证所推断故障原因的正确性
推断出根本性故障原因之后，接下来就要制定可能的故障解决方案（或临时工作环境）和具体的实施计划。由于实施故障解决方案时通常要对网络实施变更操作，因而如果企业定义了日常网络维护流程，那么就必须遵循相应的变更管理流程。下一步就是评估这些变更对网络产生的影响，并在变更影响与故障紧急程度之间做出平衡。如果故障紧急程度大于变更操作所带来的影响，那么就可以实施变更操作。需要注意的是，必须确保能够恢复到实施变更操作之前的状态，这是因为即使相信自己推断出的根本性故障原因极有可能就是真正的故障原因，而且也相信自己提出的解决方案确实能够解决该故障，但是毕竟无法完全确定该解决方案能够真正解决故障。如果未能解决故障，那么就需要取消所作的全部变更操作并恢复到原始状态。根据企业的变更管理流程，只有在制定了回退方案之后，才能实施建议解决方案。接下来需要验证故障是否已解决以及变更操作是否达到了预期目标。换句话说，要确认故障的根本性原因及故障现象已被彻底解决，而且所实施的故障解决方案没有引入新的故障。如果所有结论都正常且达到了期望目标，那么就可以进入故障检测与排除进程的最后阶段（将故障解决方案集成到网络维护进程中并更新网络文档）。图2-7显示了实施和测试故障推断的任务流程，一种可能是解决了故障，另一种可能则是回退所实施的变更操作。
排障人员必须做好故障未被修复、故障现象未消失或者因变更操作引入新故障等情况的紧急预案。此时需要执行回退方案，将网络恢复到原始状态，并重新开始故障检测与排除进程。在这种情况下，就要确定究竟是所推断的根本性故障原因不对还是所实施的故障解决方案未奏效。
2.1.7 解决故障并记录排障过程
证实了故障推断并确信故障现象已经消失之后，就表明已经完全解决了该故障，此时唯一要做的就是将变更操作集成到网络的日常实施流程中，并执行与这些变更操作有关的所有维护流程。需要对所有发生变更的配置或实施升级的软件进行备份，并将所有变更情况详细记录到网络文档中，以确保网络文档准确记录了网络的当前状态。此外，还要执行企业规定的所有变更控制流程。从图2-8可以看出，在故障推断验证成功之后、汇报故障已解决之前，需要将故障解决方案融入日常网络实施流程中，并执行备份、编制网络文档以及沟通等收尾工作。需要注意的是，故障检测与排除实践要求确定了故障原因并实施了故障解决方案之后，还要提出相应的建议措施，以便在未来避免再次出现类似故障或者减小类似故障的出现概率。
最后要做的就是向相关部门或人员汇报故障已解决。至少要与报告故障的用户进行沟通，如果在故障上报进程中涉及了其他部门或其他人员，那么还要与他们进行沟通。对于上述进程和流程来说，每个企业组织都必须确定应该描述、制度化或遵循哪些进程及流程。回顾这些故障检测与排除进程并与自己的排障习惯进行对比，对于每个排障人员来说都是有益的。