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

Speak in British English with a confident, authoritative, and conversational tone - like a senior network consultant briefing a client over a coffee. Measured pace, clear diction, occasional dry wit. Not a lecture. Not a sales pitch. Just straight talk from someone who has seen this problem a hundred times: 欢迎来到 Purple 技术简报。今天我想和大家聊聊每位网络经理都深有体会、甚至可能早就习以为常的一件事，即使他们从未听过其正式名称。那就是“平均证明清白时间” - 即 MTTI。[短暂停顿] 也就是你用来证明“这不是我的问题”所花费的时间。 让我们来看这样一个场景。早上九点，一栋租房公寓（build-to-rent）的住户开始给前台打电话，说 WiFi 坏了。物业经理致电托管 WiFi 服务商，托管 WiFi 服务商联系 ISP，ISP 让检查路由器，路由器团队让检查接入点，接入点厂商又让检查客户端设备。在这一来一回折腾中，45分钟过去了，却没有任何人真正解决问题。这就是典型的“平均证明清白时间”在作祟。[短暂停顿] 而它给你带来的损失远超你的想象。 让我来给它下一个准确的定义。平均证明清白时间是指从检测到问题开始，到任意给定团队能够用证据证明其管辖领域并非根本原因所经历的平均时间。它不同于平均识别时间（MTTI），后者是整个组织层面用于寻找真正根本原因的指标。而 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 的分界点。你需要跨越这些边界的路径跟踪数据。不仅仅是对 8.8.8.8 进行 ping 操作。而是实际的 traceroute 样式可见性，向你展示每一跳、其延迟以及是否在丢包。当你能够展示第 1 到 4 跳是干净的，而第 5 跳（即 ISP 的边缘路由器）显示有百分之四十的丢包时，对话局势立见分晓。 第三层：具有按需数据包捕获功能的流数据。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 解析时间在早上7:43从12毫秒激增至400毫秒。WiFi 层是健康的。路径追踪显示延迟是在第三跳引入的，即 ISP 的汇聚路由器。提供商向酒店经理发送了一张路径追踪的截图，其中用红色突出了性能下降的跳数，同时附带的合成测试图表显示 WiFi 层在整个过程中都是干净无故障的。随后联系了 ISP。ISP 确认了他们那边的路由问题。从收到投诉到证明 WiFi 层无责的总耗时：6分钟。整个事件的 MTTR（平均恢复时间）：22分钟，因为 ISP 的修复花费了16分钟。如果没有可观测性工具，那6分钟的无责证明将变成40分钟的来回拉扯，而 MTTR 将会超过一个小时。 场景二：一家零售连锁店。一家在200家门店部署了 WiFi 的全国性零售商注意到，某个地区的 POS 终端与支付处理系统的连接时断时续。网络团队立刻成为了被指责的对象。流量数据表明，流向支付处理系统 IP 范围的流量干净地离开了门店网络。问题不在于网络。在支付处理系统 VLAN 上的数据包捕获显示 TCP 重传激增，这指向了支付处理系统服务器端的问题。网络团队与支付处理系统的支持团队共享了流量数据和捕获摘要。支付处理系统在其侧发现了一个配置错误的负载均衡器。网络团队的 MTTI（平均识别时间）：8分钟。支付处理系统的修复时间：35分钟。如果没有流量数据，网络团队本来会花费这35分钟去重新配置 VLAN 和重启运行完好的交换机。 好。让我针对在这个主题上经常被问到的关键问题，给您一个快速回答的版本。 是 WiFi 的问题还是设备的问题？从 AP 本身运行合成测试。如果 AP 可以干净地访问互联网而设备不能，那就是设备的问题。如果 AP 无法访问互联网，那问题就在设备的上一游。 是 WiFi 的问题还是 ISP 的问题？对互联网进行路径追踪。如果延迟或丢包是在您的网络边界之外的某一跳引入的，那就是 ISP 的问题。 MTTI 与平均识别时间有什么区别？MTTI 是您的团队证明自己无责的时间。平均识别时间是组织找到真正罪魁祸首的时间。MTTI 是平均识别时间的一个子集。如何在不购买新工具的情况下缩短 MTTI？从您现有的资源开始。大多数企业级接入点平台（包括 Cisco Meraki、HPE Aruba 和 Juniper Mist）都内置了合成测试和客户端诊断功能。利用好它们。记录您的拓扑结构。构建一个物业经理或运营团队可以查看的共享仪表板。透明度是降低 MTTI 最廉价的工具。 总结一下。在每次网络事件中，平均清白时间（MTTI）是一项隐形成本。在多租户环境中，由于责任分散在运营商、业主和 ISP 之间，该指标决定了您是能保留合同还是会失去它们。降低这一指标的方法并不复杂：合成检查、路径可见性、流量数据、拓扑映射和事件关联。目的不是为了在推卸责任的游戏中获胜，而是用共享的证据取代推卸责任，让每个团队都能专注于解决问题，而不是捍卫自己的地盘。[短暂暂停] 因为花在证明清白上的每一分钟，都是您的居民、访客或顾客在没有网络连接的情况下度过的额外一分钟。而这才是真正关键的数据。 感谢收听。如果您想了解 Purple 的多租户 WiFi 平台如何跨 80,000 个活跃场所呈现此类可观测性数据，请访问 purple dot ai。