网络故障排除科学步骤

2019-11-28 18:23:37 云杰通信 99

网络故障排除科学步骤

故障排除不是一门艺术,这是一门科学。的确,在故障排除方面具有出色技能的人可以使它看起来像是天生的天赋,就像专业球手使打本垒打变得容易一样,而实际上这是一种博学的技能。另一个常见的误解是将故障排除视为一项技能,该技能完全来自于相关技术的经验。虽然经验当然是有益的,但有效地进行故障排除的能力主要来自于系统性过程(科学)的拥护。

鉴于几乎不可能识别并记住系统或网络可能存在的所有潜在故障点,工程师必须改为学习识别和解决故障的过程。

故障排除过程

本质上,故障排除是因果之间的关联。您的代理服务器遇到硬盘故障,因此您无法再访问网页。反铲挖掘了一根电路,您不能给分支机构打电话。因果相关性显而易见。困难在于从结果到原因的过渡,而这正是其核心问题。

走进一个黑暗的房间,灯灭了,但你不知道为什么,这时我们需要找出原因。本能地,将到达电灯开关。如果电灯开着,您将寻找另一个原因。也许电源没电了。断路器可能已跳闸。也许有人偷走了所有的灯泡。不用多考虑,您就可以按照方便性或可能性的顺序研究这些可能的原因。下意识地,您正在应用一个过程来解决问题。

即使我们的灯泡比喻被认为是简单的,它也可以用来说明故障排除的基础。相同的概念可扩展到指数级更复杂的方案。从高层次来看,故障排除过程可以简化为几个核心步骤:

  1. 找出影响

  2. 消除可疑原因

  3. 设计解决方案

  4. 测试并重复

  5. 减轻

步骤1:找出影响

正确识别互联网中断或更改的影响,是故障排除中最关键的步骤。第一步判断不当可能会导致您走错路,浪费时间和资源。识别结果不应与推论可能的原因混淆,在这一步中,我们仅专注于列出网络操作偏离规范的方式。

最好不要有任何假设就确定效果。虽然在第一次中断报告时您的思想自然会跳到可能的原因,但您必须强迫自己采取客观的立场,并在没有偏见的情况下调查发现的症状。

需要考虑的一些关键点:

  • 什么正在工作并且已停止?

一个重要的考虑是开始时是否存在缺席服务。用户可能会报告由于中断而无法访问FTP站点,但由于政策问题,并未意识到防火墙始终阻止FTP连接。

  • 什么不起作用,已经开始?

这可能是不那么明显,但同样重要。一个示例可能是由于通过备用路径进行路由或删除访问控制机制而导致的流量类型或带宽限制的放宽。

  • 什么继续起作用?

是否切断了所有网络访问权限,或者仅切断了某些类型的流量?还是只有某些目的地?应变系统是否已接管发生故障的生产系统的控制?

  • 何时观察到这种变化?

这个关键点经常被忽略。我们很快就会看到,与其他事件相关必须要有时间。还请记住,我们通常仅限于注意观察到更改的时间,而不是更改发生的时间。例如,星期一早上观察到的停电很容易在前一个周末的任何时间发生。

  • 谁受到影响?

更改是否仅限于特定的用户或设备组?它是否局限于地理或逻辑区域?任何人或服务免疫吗?

  • 条件是间歇性的吗?

这种状况会消失并重新出现吗?这是按可预测的时间间隔发生的还是随机出现的?

  • 这以前发生过吗?

这是重复出现的问题吗?它持续了多久了?分辨率是多少?(您确实保留了此类记录,对吗?)

  • 与计划的维护和配置更改相关

此时是否有其他更改?是否添加,移除或更换了设备?中断是否发生在本地或其他站点或提供商的预定维护时段内?

步骤2:消除可疑原因

一旦我们对影响有一个可靠的了解,我们就可以尝试推断出可能的原因。我说可能是因为推论所有可能的原因是不切实际的,即使不是不可能的。可能的原因是电源故障。另一个可能的原因是自燃。这些可能原因中只有一种是可能的。

有一个流行的口头禅:“始终从第一层开始”,这表明在进行更高层操作之前,应先验证网络的物理连接性。我不同意这一观点,因为这具有误导性,而且通常不切实际。如果通过简单的ping验证端对端连接,您将不会驱逐到远程站点来验证是否插入了所有东西。同样,如果您可以相对确定地确认没有人靠近可疑设备,则不会有任何电缆受到干扰。也许这是一个过分简化的论点,但是验证物理连接性通常是不必要的耗时并被替代方法所取代。

相反,我建议按照概率和方便性的顺序来缩小范围。例如,可能没有任何迹象表明DNS返回的响应无效,但是执行手动名称解析大约需要两秒钟,因此这很容易做到。相反,将当前设备配置与其已使用一周的备份进行比较并考虑所有差异可能会花费大量时间,但是这很可能暴露原因,因此也很合理。

您决定消除可疑原因的顺序最终取决于您的经验,对基础架构的熟悉程度以及时间的允许。无论优先级如何,每个可疑原因都应经过相同的消除过程:

  • 定义工作条件

除非您知道期望什么条件,否则您无法测试条件。在执行测试之前,您应该记住在没有中断的情况下应该产生什么结果。例如,如果不能在正常情况下将其与到相同目的地的跟踪路由进行比较,则执行到远方节点的跟踪路由是没有意义的。

  • 为该条件定义一个测试

确保您执行的测试实际上正在评估可疑原因。例如,对电子邮件服务器执行ping操作并不明确保证邮件服务可用,仅保证服务器本身可用(技术上,仅保证该服务器的地址)可用。要验证邮件服务的存在,必须建立与相关守护程序的连接。

  • 应用测试并记录结果

应用测试后,请在笔记中记录其成功或失败。即使您已经消除了怀疑的原因,您也可以参考一下,以免浪费不必要的时间重复进行相同的测试。

在故障排除过程中通常会发现多个故障。发生这种情况时,识别任何依赖关系很重要。例如,如果您发现电子邮件,Web访问和中继链接都已关闭,则如果电子邮件和Web故障依赖于中继链接起作用,则很可能会被忽略。但是,始终记得在解决了主要故障之后,验证这些假定的辅助故障。

步骤3:设计解决方案

一旦确定了故障点,我们就想继续我们的系统方法。就像测试失败一样,我们可以将简单的方法应用于测试解决方案。实际上,该过程非常紧密地反映了为消除可疑原因而执行的步骤。

  • 定义失败

此时,您应该对失败有一个轻松的了解。形成详细的说明,以便在应用解决方案后可以进行测试。例如,您想将“ Internet断开”细化为“建筑物10中的用户无法访问Internet,因为其子网已从防火墙上的出站ACL中删除”。

  • 定义建议的解决方案

准确描述要进行的更改以及预期的结果。一揽子解决方案(例如,任意重新启动设备或从头开始重建配置)可能会解决此问题,但它们会阻止任何进一步的诊断,从而阻碍缓解措施。

  • 应用解决方案并记录结果

一旦我们确定了故障并提出了解决方案,就该使两者相互对立了。在应用解决方案时要保持警惕,并记录其结果。结果是否符合您的预期?故障是否已解决?

除了我们定义的过程外,还有一些准则值得一提。

  • 保持专注

我经常遇到一名技术人员,一旦对故障感到沮丧,他们选择不计后果地重新启动,重新配置或更换设备,而不是系统地进行故障排除。这在高科技上相当于用锤子砸东西直到起作用。一次关注一个故障,每次故障一次关注一个解决方案。

  • 当心危险变化

在开发解决方案时,请记住评估该解决方案可能对与故障排除无关的系统产生什么影响。意识到您已解决一个问题却以造成更大问题为代价,这真是一种恐怖的感觉。发生这种情况时,最好的措施通常是立即撤消所做的更改。注意,这只有通过系统的方法才有可能。

步骤4:测试并重复

在实施解决方案并观察到积极效果之后,我们可以开始将步骤追溯到原始症状。如果由于决定依赖于最近解决的故障而忽略了任何条件,请再次进行测试。请参阅初始报告中的注释,并确认每种症状均已解决。确保使用用于识别故障的相同测试来确认功能。

如果您发现仍然存在一个或多个失败,请在测试周期中停下来的地方重新进行注释,然后向前推动。

步骤5:减缓

解决问题并且每个人都很高兴时,故障排除过程不会结束。如果明天再次发生相同的问题,那么到现在为止,您付出的所有辛苦工作几乎不会发生。在IT中,问题通常是固定的,没有解决过。创可贴和仓促的安装不是实现永久和可靠解决方案的可接受的替代方法。可以这么说,许多人将日复一日地擦地板而不会堵塞泄漏。

永久性解决方案可能与重新设计路由主干网一样复杂,也可能像将配电盘移到不再绊倒一样简单。永久解决方案也不必一定是100%有效的,但是它应该与实际一样有效。绝对最低限度,请确保您记录观察到的故障和所应用的解决方案,以确保在这种情况再次发生时,您可以获得准确的,过时的参考。

最后的话

每个人在故障排除方面都有自己的方式,我绝不认为本文具有结论性。但是,如果只有一个概念可以接受,那就做到这一点:首先,保持冷静。恐慌对任何人都不好。一个人即使在完全混乱的情况下也能管理压力并保持专业的举止,才是一个好的工程师的素质。尽管我们高层认为,大多数网络中断都会是世界末日。幸运的是,绝大多数网络都不是这种情况。金钱可能会浪费,时间可能会浪费,感情可能会受到伤害,但是当问题最终解决后,您很有可能学到了一些有价值的东西。