网络基础设施故障排除是一个多层次的过程--从模糊的 "有问题 "到具体问题的根本原因分析。这个过程越规范，对网络行为和影响终端用户的问题之间的相关性理解得越透彻，问题就能越快地得到解决或交给适当的团队进行补救。
这个过程中常年面临的挑战是，用户投诉通常是模糊的。用户(无论是员工、客户，甚至是对网络条件敏感的算法)通常会遇到三种情况："我无法连接"、"网络太慢 "或 "我的语音/视频通话质量不好"。由于每一种情况都可能是由多个潜在问题引起的，因此IT团队往往难以缩小事情的范围。例如，网络速度慢可能是由网络、应用程序或协议延迟引起的，其中每一个都可能通过任何一个不同的指标显示出来。但对于沮丧的终端用户来说，这一切看起来都是一样的--而且很多东西可能会在转换中丢失。
为了找到根本原因并加快问题的解决，IT团队不仅需要正确的工具来评估网络指标，还需要清楚地了解用户体验、可测量的网络行为和潜在网络问题之间的相关性。为了说明这一点，让我们来看看故障排除的过程。
第一步：收集相关指标
各组织依靠许多来源和类型的网络数据来为终端用户的投诉提供背景。他们的基本需求是建立网络监控基础设施，以便IT能够访问数据包数据、流量数据、事件和遥测数据以及服务器KPI。这将为他们提供所需的洞察力，以确定各种场景的根本原因。有一些特定的指标与具体问题相关。对于 "网络很慢"，相关指标将是单向延迟、往返时间、Z-Win、DNS或HTTP延迟、吞吐量(Gbps)、每秒数据包(PPS)、每秒连接数(CPS)或并发连接数(CC)。对于 "质量差"，要看抖动、序列错误、重传和碎片。当 "连接性 "是问题时，检查ICMP、HTTP和SYN/ACK错误。
第二步：缩小问题范围
一旦IT团队获得了所需的数据，他们就可以开始关联各种网络行为，以排除可能的原因，并将实际问题归为零。这根据他们所要解决的投诉而有所不同。
网络速度慢--这很可能是由网络过载引起的，但也有可能是服务器太忙或DNS服务器没有响应。正如讨论过的，相关的指标是单向延迟(网络问题)、往返时间或Z-Win(应用问题)，以及DNS或HTTP延迟(协议问题)。如果网络延迟很高，那么要么是网络上的整体流量太大，要么是 "爆棚"。观察整体性能和吞吐量(Gbps)、每秒数据包(PPS)、每秒连接数(CPS)或并发连接数(CC)应该有助于确定是哪一种。如果应用或协议延迟是原因，那么可以将问题传递给相应的团队来解决。观察数据包和流量数据对于排除缓慢网络的故障尤为重要。流量数据可以识别每秒的*通话者或数据包，但它无法判断网络的突发程度或每秒的连接数--这需要数据包数据。
质量差--IT应该监控抖动、序列错误、重传和碎片，以诊断这些投诉。高比率的抖动和序列错误表明问题出在网络流上，而重传和碎片则表明问题出在数据包丢失上。这些问题可能是由路由问题或MTU(最大传输单元)碎片配置错误引起的。
连接性 - 这种投诉可能是由认证、授权或设备的访问控制列表中的错误问题引起的。要弄清楚是哪一种，IT团队应该首先查看相关设备的协议错误。接下来，他们应该检查连接错误，比如查看数据包数据是否有SYN/SYN ACK错误，以确保客户端和服务器之间的TCP/IP三方握手是完整的。
第三步：找出根本原因
至此，IT部门应该已经找到了问题的根本原因，可以着手进行补救。问题经常是网络配置错误，但其他的可能性包括网络设备故障、应用程序错误或bug、DDoS攻击或某些其他安全事件。但是，如果不能访问广泛的网络指标和数据包数据，IT人员将不得不猜测到底是哪个问题在起作用。