这篇关于网络故障排除的博客是我的“回归基础”系列文章的第五篇。前四个博客都提到了收集需求,网络设计、网络实现和网络操作。
排除问题是一个很好的时机，要记住网络是在IT堆栈的底部。这一事实并不意味着网络应该被视为比堆栈中的其他组件更不重要。恰恰相反，处于底层意味着它是一切的基础。网络还处于能够从端到端观察问题的独特位置。
我能为您效劳吗?
当问题出现时，人们的第二天性就是为他们的制度寻求快速的免罪。这种行为适用于应用程序开发人员、数据库管理员和系统管理员，也适用于存储和网络管理员。指责某人的系统是问题的根源，就像说他们的孩子丑一样。简短的交流也许是你所希望的最好的方式。
这种“少花钱多办事”的文化在当今的企业世界中无处不在，这意味着用于维持工作状态的人力资源，同样也是用于开发和实现新功能的资源。降低平均清白时间(MTTI)可以留下更多的时间来处理增强和更改请求，从而推动业务向前发展。试图证明清白的困难在于，问题会像烫手山芋一样在团队之间传递，根本原因往往无法发现。这种行为会导致重复出现问题，从而减少帮助业务的时间。
这一切都是为了说明，当需要你的技能来解决一个问题时，要尽你最大的能力去做。当网络因为一个问题而受到指责，而不是被礼貌地要求检查它是否能帮助解决一个问题时，把重点放在支持和服务上。不要把注意力集中在指责上。不要假设网络是无辜的，而要用尽您的故障排除方法，直到在系统的某个地方找到根本原因。这需要时间，但这种程度的努力和关心将建立信任和信誉。
策划袭击
当你第一次遇到一个问题时，你应该问这两个问题:
- 这个系统起作用了吗?
- 做了任何东西改变吗?
这些问题的答案将有助于锁定攻击目标。
在处理复杂问题时，具有可重复的、可适应的故障排除方法是至关重要的。以下只是许多行业中数十个文档中的几个例子。
- OODA循环:“观察、东方、决定、法案”是由美国空军的约翰·博伊德上校制定的。
- PDCA:计划、执行、检查、行动是丰田公司为支持其精益生产流程而开发的一种管理方法。
- GTD:捕捉、澄清、组织、反映和参与是大卫·艾伦的“把事情做好”生产力方法的基础。
虽然这些示例并不特定于故障排除，但它们都很简单，并且具有允许轻松迭代的公共元素。这些要素可以概括为以下基本步骤:
- 观察并记录症状
- 就可能的根本原因在哪里或在哪里可以进行更好的观察发展一种理论
- 决定最好的行动方案
- 行为
- 冲洗和重复，直到问题被解决
分而治之
在这篇网络运营的文章中，我讨论了网络可见性工具的重要性。故障排除是这些工具的用武之地。如果从第一天起就内置了网络可见性，那么这些工具可能已经捕获了症状，从而可以立即进行分析。如果不是，收集和分析证据可能要等到问题再次发生。等待安装和配置工具可以扩展间歇性问题的问题解决方案。
看看下面的图，应该很容易看到，在网络中有多个观察点可以更容易地找出问题所在。图1有一个观察点。根据症状，可能很难判断问题是在这一点的右边还是左边。图2显示了两个观察点。根据症状，应该更容易判断问题是在两个点的右边，还是在两个点的左边，还是在两者之间。增加更多的观察点可以更快地缩小搜索区域。
图1:单个观察点
图2:双重观察点
我们都在一起
IT的目标是帮助使业务达到最佳状态。当支持业务的系统出现问题时，信息技术的所有部门都需要站出来，成为解决方案的一部分。出于许多原因，这种情况并不总是发生。在任何情况下，我们只能控制自己。个人的积极、响应、开放和服务意识对建立信誉、信任和高绩效团队大有帮助。
阅读我的其他博客的回归基础系列
收集需求
