技能介绍

先搞清「慢」和「不通」差在哪

网络故障刚冒头时，最常见的困境不是没有告警，而是只有一句「访问超时」或「延迟高了」。运维拿到这条信息后很难直接行动：用户说打不开页面，可能是本机路由错误，可能是 ISP 出口拥塞，也可能是目标机房的入口防火墙丢包。如果直接把工单升级成「大面积故障」，往往会浪费大量排查时间，甚至把正常波动当成事故。这个技能要解决的问题很具体：在准备升级停机之前，先拿到能定位到具体跳数的丢包与延迟证据。

用 Trippy 把路径逐跳拆开

技能的核心工作方式基于 Trippy 的持续路径测量能力。它不像 ping 只告诉你端到端能不能通，也不像普通 traceroute 只给一份一次性结果，而是像 mtr 一样反复发送探测包，并把每一跳的统计信息持续汇总。

关键步骤包括：

从当前主机向目标主机发起逐跳测量，记录经过的网关、边缘节点和入口设备。
分别观察延迟（RTT）、抖动（jitter）、丢包率（packet loss） 和每一跳的可达性。
对比不同时间窗口的统计结果，判断问题是偶发拥塞、持续丢包，还是某一段链路突然劣化。
当看到前几跳正常、中间某跳开始丢包时，就能把故障范围缩小到具体 ISP、专线段或目标网络边界，而不是把整条路径都列为嫌疑对象。

如果延迟整体上升但丢包很少，通常更偏向带宽或路由绕行问题；如果某一跳之后丢包突然增加，则很可能说明该节点、该链路或其背后的设备才是瓶颈。

适用边界和注意点

这个技能适合 Linux、BSD、macOS 和 Windows 等常见桌面与服务器环境，但它并不是万能的网络诊断器。首先，它需要 Trippy CLI、终端访问权限，以及到目标主机的网络可达性。部分系统还需要提升权限才能使用底层 ICMP/UDP 探测；如果环境不允许特权运行，需要确认对应 OS 是否支持受支持的权限绕过方式，否则探测结果可能不完整。

其次，测量结果也会受到中间网络策略影响。某些云厂商、防火墙或 ISP 会限速、改写 ICMP，甚至对探测包做异常处理，导致你看到的跳数、延迟和丢包只是策略过滤后的近似结果。因此，技能的价值在于提供路径证据，而不是直接给出根因结论。在升级停机之前，它能帮助团队把「网络不稳定」拆成「哪一段在丢包」，但如果问题发生在目标应用内部、TLS 握手或 DNS 解析，仍需要结合其他工具继续排查。