平均无罪时间：如何证明问题不在 WiFi

以英式英语发言，语气自信、权威且具有对话性——就像一位资深网络顾问在喝咖啡时向客户做简报。节奏沉稳，吐字清晰，偶尔带点冷幽默。不是讲座，也不是推销。只是来自一个见过这种问题上百次的人的坦诚交流： 欢迎收听 Purple 技术简报。今天我想和大家聊聊每位网络经理都深有体会的一件事，即使他们从未听过它的正式名称。平均无罪时间，简称 MTTI。[短暂停顿] 也就是你用来证明这不是你的错所花的时间。 设想这样一个场景。早上九点。一栋长租公寓（build-to-rent）的住户开始给前台打电话，说 WiFi 坏了。物业经理打电话给托管 WiFi 服务提供商。托管 WiFi 服务提供商打电话给 ISP。ISP 说检查路由器。路由器团队说检查接入点（AP）。接入点厂商说检查客户端设备。在这中间，四十五分钟过去了，实际上却没有任何人解决任何问题。这就是平均无罪时间在起作用。[短暂停顿] 而且它给您带来的损失比您想象的要大。 让我来给它下一个准确的定义。平均无罪时间是指从检测到问题到任何特定团队能够用证据证明其管辖领域并非根本原因之间所经历的平均时间。它与平均识别时间不同，后者是衡量寻找实际根本原因的全局指标。MTTI 是孤立的、针对特定领域的。它是网络团队在说：‘数据在这，不是我们的问题，去别处看看吧。’ 问题在于，如果没有合适的工具，这种证明需要时间。而 MTTI 的每一分钟都会直接增加到您的平均解决时间（MTTR）中。这两者是密不可分的。 那么，为什么 WiFi 总是第一个被指责呢？[短暂停顿] 原因有三。首先，WiFi 是可见的。当网络中断时，人们会看向他们能看到的东西，而手机上的 WiFi 信号条就是最显眼的连接指示。其次，WiFi 是设备前的最后一跳，因此当设备无法访问互联网时，它首先会显得可疑。第三，这也是让人有些难堪的一点，WiFi 团队往往因为缺乏合适的遥测数据而无法快速证明自己的清白。如果您无法在两分钟内证明无线层运行正常，那么接下来的一个小时您都将忙于为自己辩护。 在单租户企业环境中，这很令人恼火。但在多租户环境中，这会带来真正的损害。想想一家像 Premier Inn 这样的酒店，或者一栋长租公寓，亦或是举办连续会议的会议中心。物业经理并不拥有网络，住户或访客不了解网络，而托管 WiFi 提供商负责无线层，但不负责 ISP 线路、楼内布线或客户端设备。当出现故障时，物业经理会指责 WiFi 提供商，因为那是他们可以追究的合同方。住户会指责大楼，因为他们向大楼支付租金。而 WiFi 提供商必须快速为网络洗清嫌疑，否则合作关系就会恶化。[短暂停顿] 在这种情况下，MTTI 不仅仅是一个技术指标，更是一个商业指标。 那么，让我们来谈谈能够切实缩短这一时间的具体方法。它分为五个层级，缺一不可。 第一层：持续主动检查。在任何工单提交之前，您应该让网络自身运行自动化探测，测试 DNS 解析、HTTP 可达性、已知端点的延迟以及认证流程。像 Juniper Mist 的 Marvis，或者 ThousandEyes 等平台中内置的主动测试，每隔几分钟就会运行一次这些检查。当事件发生时，您可以拉出图表，准确展示 WiFi 层上一次进行正常主动检查的时间，以及在投诉发生时它是正常还是降级的。单凭这一点就能大幅缩短 MTTI，因为您要么确认了 WiFi 是健康的，要么确认了它不健康，从而停止无休止的争论。 第二层：逐跳路径可见性。这是大多数团队折戟的地方。您可以证明接入点是健康的，也可以证明交换机是健康的。但您能证明从交换机到 ISP 交付点的路径是健康的吗？在多租户大楼中，通常存在不属于您的节点。楼内分配网络、业主的物理核心交换机、与 ISP 的分界点。您需要跨越这些边界的路径追踪数据。不仅仅是 ping 8.8.8.8，而是真正的路由追踪式可见性，显示每一个跳点、其延迟以及是否丢包。当您可以展示第一到第四跳是干净的，而第五跳（即 ISP 的边缘路由器）显示 40% 的丢包率时，谈话的性质立竿见影地改变了。 第三层：结合按需数据包捕获的流数据。NetFlow 和 IPFIX 为您提供网络上设备间通信的会话级视图。当住户说流媒体服务坏了时，流数据可以告诉您发往该服务 IP 范围的流量是否已经离开了网络。如果流量正常离开网络，而问题出在下游，这就是您的证据。如果流量根本没有离开网络，您就知道该去哪里排查了。在 Cisco Meraki 和 HPE Aruba 等平台上提供的按需数据包捕获功能，让您无需接触硬件即可针对特定客户端或 VLAN 进行定向捕获。这是您的取证层。您虽然不常使用它，但需要它时，它就是决定性的证据。 第四层：拓扑与依赖关系映射。在多租户环境中，您需要一张实时地图，显示哪些接入点服务于哪些租户、这些 AP 连接到哪些交换机、这些交换机使用哪些上行链路，以及服务于每个上行链路的 ISP 线路。当事件发生时，您可以立即确定爆炸半径。这影响的是单个租户还是所有租户？单层楼还是整栋大楼？单个 VLAN 还是所有 VLAN？这个通过拓扑图在三十秒内就能回答的范围界定问题，可以告诉您问题是出在 WiFi 层、大楼网络还是 WAN。它还能告诉您应该拉谁进来，以及可以立即排除谁。 第五层：事件关联。这是将一切联系在一起的关键。变更日志、ISP 维护告警、设备固件更新、电源事件和用户投诉都需要放在同一条时间线上。当您将客户端关联失败的激增与十二分钟前进行的固件推送重叠时，您就找到了根本原因。当您将延迟激增与未通知您的 ISP 维护窗口重叠时，您就拥有了升级处理的证据。事件关联并不光鲜，但它决定了您是要进行四十五分钟的推诿，还是在四分钟内洗清嫌疑。 现在，谈谈文化层面，因为这是很多团队搞错的地方。降低 MTTI 的目的不是为了更快地赢得推诿游戏，而是为了彻底终结推诿。[短暂停顿] 共享证据改变了这种动态。当 WiFi 提供商可以向物业经理发送一个仪表板链接，显示无线层为绿色、大楼内交换机为黄色、ISP 线路为红色时，对话就不再具有对抗性，而是变成了协作。物业经理致电 ISP，ISP 修复线路，住户恢复连接。而 WiFi 提供商的合同得以续签，因为他们是发现问题的人。 这就是投资可观测性工具的商业价值所在。这不仅能实现更快的故障排查，还能与向您付费的人建立更好的关系。 让我通过几个快速场景来具体说明。 场景一：一家拥有 350 间客房的酒店。一家 Premier Inn 风格酒店的住户开始报告客房内 WiFi 变慢。前台向托管 WiFi 提供商提交了工单。在运行主动检查的情况下，提供商可以看到 DNS 解析时间在早上七点四十三分从 12 毫秒飙升至 400 毫秒。WiFi 层是健康的。路径追踪显示延迟是在第三跳引入的，即 ISP 的汇聚路由器。提供商向酒店经理发送了一张路径追踪截图，其中用红色标记了降级的跳点，同时附带了显示 WiFi 层全程正常的主动检查图表。酒店致电 ISP，ISP 确认其侧存在路由问题。从投诉到 WiFi 层洗清嫌疑的总时间：六分钟。整个事件的 MTTR：二十二分钟，因为 ISP 的修复花了十六分钟。如果没有可观测性工具，这六分钟的澄清过程将变成四十分钟的反复扯皮，而 MTTR 将超过一个小时。 场景二：一家零售连锁店。一家在全国拥有两百家门店的零售商注意到，某一地区的销售点终端与支付处理系统的连接断断续续。网络团队立即受到指责。流数据显示，发往支付处理商 IP 范围的流量正常离开了门店网络。问题不在于网络。在支付处理商 VLAN 上的数据包捕获显示 TCP 重传激增，这指向了支付处理商侧的服务器端问题。网络团队与支付处理商的支持团队共享了流数据和捕获摘要。支付处理商在其侧发现了一个配置错误的负载均衡器。网络团队的 MTTI：八分钟。支付处理商的修复时间：三十五分钟。如果没有流数据，网络团队本会花费这三十五分钟去重新配置 VLAN 并重启运行完全正常的交换机。 好，让我快速回答一下我经常被问到的几个关键问题。 是 WiFi 的问题还是设备的问题？从 AP 本身运行主动检查。如果 AP 可以正常访问互联网而设备不能，那就是设备的问题。如果 AP 无法访问互联网，则问题出在设备的上游。 是 WiFi 的问题还是 ISP 的问题？对互联网进行路径追踪。如果延迟或丢包是在网络边界之外的跳点引入的，那就是 ISP 的问题。 MTTI 和平均识别时间有什么区别？MTTI 是您的团队证明无罪的时间。平均识别时间是组织找到真正罪魁祸首的时间。MTTI 是平均识别时间的一个子集。 如何在不购买新工具的情况下降低 MTTI？从您现有的工具开始。大多数企业级接入点平台，包括 Cisco Meraki、HPE Aruba 和 Juniper Mist，都内置了主动测试和客户端诊断功能。利用好它们。记录您的拓扑结构。构建一个物业经理或运营团队可以看到的共享仪表板。透明度是降低 MTTI 最经济的工具。 总结一下。平均无罪时间是每次网络事件中的隐形成本。在责任分散在服务提供商、业主和 ISP 之间的多租户环境中，它是决定您是留住合同还是失去合同的指标。降低它的方法并不复杂：主动检查、路径可见性、流数据、拓扑映射和事件关联。目标不是为了赢得推诿游戏，而是用共享证据取代推诿，以便每个团队都能专注于解决问题，而不是捍卫自己的地盘。[短暂停顿] 因为证明无罪所花费的每一分钟，都是您的住户、访客或顾客在没有网络连接的情况下度过的一分钟。而这才是真正关键的数字。 感谢收听。如果您想了解 Purple 的多租户 WiFi 平台如何在 80,000 个活跃场所中呈现此类可观测性数据，请访问 purple dot ai。