一、背景：监控画面“卡一下”、“花一下”，但带宽充足

在白虎科技实习期间，我们负责某单位的监控网络维护。一天物业反馈：

“监控最近老是卡一下，尤其是晚高峰画面会花屏。”

常见猜测一般有：
    •    云台摄像头带宽不足？
    •    摄像头码率过高？
    •    存储服务器压力变大？
    •    摄像头硬件老化？

但经过初步检测：
    •    摄像头负载正常
    •    带宽不到上限的一半
    •    存储写入速度正常
    •    交换机无风暴告警

带宽没满，码率正常，监控却卡顿。
这是一个典型的“网络质量问题”，而非“网络容量问题”。

二、第一阶段：排除摄像头端问题

✔ 摄像头 CPU 正常

无 100% 占用情况。

✔ 摄像头码率稳定

码率波动小，无过载压缩情况。

✔ 摄像头链路无环路

线路直连，无 PoE 供电不足现象。

摄像头端完全正常。

三、第二阶段：重点排查交换机上联口

虽然摄像头本身没问题，但视频卡顿常常来自：

交换机 uplink 上联口出现丢包/抖动。

于是我查看了上联口的端口统计。

结果一眼就看到了异常：
    •    上联口出现 CRC 错误（循环冗余校验错误）
    •    输入丢包持续上升
    •    单播帧异常低，广播正常

这说明：
    •    链路质量不稳定
    •    上行端口可能存在物理层问题
    •    包在传输过程中发生损坏

导致摄像头画面偶发卡顿。

问题的方向已经非常明确。

四、第三阶段：确认是否为物理链路造成的丢包

我们进一步排查：

✔ 更换跳线

替换后丢包下降，但仍存在。

✔ 查看光模块温度

正常，无过热。

✔ 查看光纤衰耗

衰耗值偏高，接近阈值（但尚未报警）。

由此推断问题可能出在：

弱光纤老化 + 路由器端口老旧 → 组合导致不稳定丢包。

这是老楼监控网络非常常见的场景。

五、最终解决方案：重做光纤接续 + 调整 VLAN 隔离

我们采取了三项措施：

① 重新冷接光纤

衰耗从 4.1 dB 降至 1.2 dB。
（正常接入一般应 < 3 dB）

② 更换上联口端口

换到一个健康端口后，CRC 错误归零。

③ 加强监控 VLAN 隔离

避免广播帧对摄像头流影响。

处理完成后，监控延迟、卡顿、花屏现象全部消失。

六、这次排障给我带来的成长

① 真正理解“延迟 ≠ 带宽不足”

很多人以为：

“画面卡 → 带宽不够”

但真实的监控网络故障中：
    •    70% 是丢包导致
    •    20% 是抖动导致
    •    只有 10% 是带宽不足

这次让我真正建立了“质量问题”与“容量问题”的区分能力。

② 第一次真正深入解释 CRC 错误的业务影响

CRC 不只是一个数字，而会直接导致：
    •    关键帧丢失
    •    画面解码失败
    •    完整帧重传
    •    摄像头回退至更低质量

这次我第一次把“底层网络指标 ↔ 业务体验”联系起来。

③ 学会根据端口统计判断链路类型问题

通过端口统计，我学会了：
    •    单播低、广播正常 → 可能是上联问题
    •    CRC 持续涨 → 物理层损坏
    •    Input Error → 上游设备不稳定
    •    Output Error → 本端口发不出去

这是教科书里学不到的。

④ 我第一次真正参与光纤重接与验证

原本以为光纤只需要“插上去就行”。
但实际只要有一点损耗超标，就可能导致业务延迟。

亲自验证接续质量，让我对物理层的理解更系统。

七、总结：监控卡顿，是网络运维最能暴露“基本功”的场景

这次排障让我深刻理解：

视频监控是最能暴露网络质量问题的业务。

因为：
    •    它对丢包敏感
    •    它对抖动敏感
    •    它的数据量大
    •    它不能重试太多次
    •    它是实时业务

做好监控网络，就是对运维基本功的最好检验。