作为一名运维，小派总能感受到来自程序员的恶意。
现在的软件和APP，但凡出了点什么毛病，不管是程序问题还是网络问题，界面弹出的报错提示八成都是“网络异常，请检查网络”。
开发省事了，用户信以为真了——网络运维：这锅我熟。
干运维这行，背锅是常态。毕竟业务一旦卡顿，网络往往是第一个被怀疑的对象。
但问题在于，造成卡顿的原因千千万。带宽不足会卡、传输有延迟会卡、设备策略限制了会卡、服务器性能太慢还会卡……
问题找到了还则罢了，要是迟迟定位不到，查来查去没个结果，最终这口锅，就只能稳稳地扣在运维的头上。
前段时间，我们就遇到了一个挺典型的场景。 某单位业务部门反馈访问多个应用时出现卡顿，但运维检查发现，Ping对面是通的，出口带宽也远没有跑满。 带宽没满，业务却卡，这就有意思了。
带宽没满，就能说明网络没问题吗？
还真不能。 带宽主要反映链路资源的使用情况，Ping则能帮助我们判断网络连通性和基本响应情况。但这两项指标正常，并不意味着业务访问的每个环节都没有问题。 当你打开某个网页，中间要经过内外网的传输、服务器接收请求、处理业务，再返回结果。任何一个环节出了状况，都可能让你觉得，这网怎么这么卡。
可问题来了，用户只会感受到页面转圈，怎么把这个模糊的体验，变成更具体的排查线索？
这就要说到Panabit的经典功能——三段时延。
什么是三段时延？
熟悉Panabit的朋友都知道，在查看某个IP的连接信息时，会展示每个连接的客户时延、服务时延和应用时延。
这些都是什么意思，有什么用呢？
简单来说，三段时延就是把客户端与服务器之间一次完整的会话交互过程，基于Panabit这个监测点，精准拆解为三个维度的独立指标。
三段时延原理示意 # 客户时延 反映客户端到监测点（Panabit）之间的网络时延。 如果这个指标异常偏高，说明需要优先排查内网，比如无线AP、交换机和内网设备策略等方面。 # 服务时延 反映监测点到业务服务器之间的时延。 若服务时延偏高，就需要进一步检查监测点往外的中间网络，比如运营商链路。 # 应用时延 反映业务服务器自身的响应时延。 若应用时延过高，说明需要排查业务服务器自身的问题，比如负载过高、数据库查询耗时长等。
需要注意，三段时延并不能直接告诉我们具体是哪台设备、哪条链路出了问题。某一段时延偏高，只能说明这部分范围值得重点关注。 但对排查来说，这已经很有价值了。 复杂问题就怕没有方向，三段时延的作用就是迅速划清责任边界，先把问题归类到内网、中间链路还是业务服务器。边界一清，排查范围立马缩小，接下来的工作就有了明确的指向。
这次，问题终于不用靠猜了
回到开头的案例。
面对“带宽没满、业务很卡”的怪象，运维人员在出口挂上了Panabit看质量监测。
结果显示，多个业务会话的服务时延和应用时延正常，但客户时延偏高，排查方向因此转向了内网。
有了这个明确的方向，沿着内网链路逐层梳理，很快就找到了根因。 原来是内网串接的一台行为管理设备，此前曾记录过一条UDP Flooding告警，触发了其自动防御机制，对单IP设置了30条并发会话的限制。 用户一旦多开几个浏览器标签页或者后台进程，并发会话就很容易超，直接导致上网卡顿。 解除限制策略后，访问恢复正常，问题解决。
正好原来的行为管理也过保了，正好Panabit也擅长。最终，Panabit顺理成章接过了原有设备的工作。
结语
许多时候，故障之所以难查，不是运维技术不行，而是他们手里缺乏粒度足够细的数据指标，只能凭经验盲目猜测。
三段时延的意义，就在于把原本不可见、不可控的模糊体验，剥离成清晰可量化的客观数据。它不一定能直接帮你排查出问题的具体设备，但它能让你在几秒钟内看清方向，更有依据地判断问题出在哪里。