接手一个没人管的实验室网络：23 台设备、400 项监控、故障恢复从 4 小时降到 15 分钟

项目速览：实验室网络原为逐台 SSH 手工配置，监控仅覆盖部分设备，故障平均 4 小时才能恢复。改造后通过锐捷 RG-QNC 控制器统一纳管 23 台交换机，监控按子网分布式部署、覆盖 400 余项指标，故障平均恢复时间降至 15 分钟。

项目名称	实验室 SDN 网络与监控体系改造
起止时间	2024.06 – 2025.04
我的角色	负责整体方案设计、设备纳管、监控架构升级与落地
技术栈	锐捷 RG-QNC 控制器、Zabbix、SNMP、VLAN、Linux
覆盖规模	23 台交换机、10 台物理服务器、30 余台虚拟机、60 多个终端
解决什么问题	网络靠手工配置容易出错、故障发现慢、没人说得清网络里到底有什么
最终结果	设备 100% 纳管、400 余项监控指标、故障平均恢复时间 4 小时 → 15 分钟、告警响应效率提升约 90%
技术亮点	配置从“逐台敲命令”变成“一次下发”、监控按子网分布式部署避免单点、量化指标有可解释的统计口径

一个实验室规模的网络，最容易掉进的陷阱是"它能跑，所以没人动它"。

我接手时的状态是这样的：二十多台交换机，VLAN 靠一台台 SSH 上去敲；监控分散在几个不同的工具里，一部分设备有监控，一部分完全没有；出了故障先靠人报，再靠人猜是哪一段的问题。

改造的成果被写成了四个数字：23 台交换机、10 台物理服务器、30 余台虚拟机、60 多个终端，400 余项监控，覆盖率 100%，故障平均恢复时间从 4 小时降到 15 分钟。

数字很漂亮，但真正需要交代清楚的是：这 4 小时怎么算的。这篇把改造做了什么、数字怎么来的、以及哪里做错了都写清楚。

一、起点：问题不在"有没有工具"，而在"有没有唯一事实"

接手时的资产清单是这样的：

类别	数量	管理方式
交换机	23 台	逐台 SSH 手工配置
物理服务器	10 台	部分接入监控
虚拟机	30+ 台	无统一视图
终端	60+	完全不可见

这些数字本身就是问题：没人能准确说出网络里到底有什么。 资产清单靠 Excel 维护，改一次配置同步一次表格，漏记是常态。等到排查故障，先要花时间搞清楚"这台设备在哪、归谁管、配的是什么"。

所以改造的第一步不是选工具，是承认手工维护的资产表一定不准，然后让设备自己上报事实。

二、控制器：把"逐台配置"改成"一次下发"

选型上用的是锐捷 RG-QNC 控制器。选择它的原因不是功能最强，而是实验室的交换机本来就是锐捷的——厂商控制器能直接纳管同厂商设备，不需要额外适配层。

为什么非要用控制器

逐台 SSH 的方式有几个绕不过去的问题：

1. 配置漂移。 23 台交换机，同一个 VLAN 在 20 台机器上配置一遍，只要有一台敲错一个数字，网络就会出现"大部分正常、局部诡异"的问题。而这种问题最难查——因为"看起来配了"。

2. 无法审计。 谁在什么时候改了哪台设备的什么配置，SSH 方式下没有任何记录。出了问题只能靠回忆。

3. 变更成本高。 加一个 VLAN，要登录 23 次。这个成本高到让人倾向于"能不加就不加"，于是网络的演进被运维成本压住了。

用控制器之后，这三件事都变了：

旧：人 → SSH → 交换机1、交换机2 ... 交换机23
新：人 → 控制器（模板 + 变量）→ 批量下发 → 23 台

关键不是"少敲键盘"，而是配置变成了声明式的：我描述"这个端口应该属于哪个 VLAN"，而不是"在这台设备上敲这条命令"。前者的正确性可以校验，后者只能靠人不出错。

配合控制器还解决了资产准确性：设备上线后自动被控制器发现并纳入拓扑，资产清单从"人工维护"变成"设备上报"，漏记的可能性从根上消失了。

一个必须承认的边界

控制器纳管有个前提：设备得支持、固件得够新、网络得通。老型号交换机进不了控制器，只能留在手工管理里，或者换掉。

这类改造最怕的就是"以为全覆盖了"。所以纳管之后我做的第一件事是核对数量——控制器里数出 23 台，跟现场实际清点对上，才算真的覆盖。数量对不上，说明有设备在控制器视野之外，那种设备的故障永远查不到。

三、监控：单节点撑不住，就得横向摊开

监控这块原本是"能用"的状态：一个 Zabbix 实例，采一部分设备。问题在于采集能力和被采对象是一对多的关系，设备一多就顶到天花板。

单节点的瓶颈在哪

Zabbix Server 的采集是轮询模型：每个监控项一个采集周期，Server 要在周期内把所有 item 采一遍。监控项数量上去之后，瓶颈依次出现在这几个地方：

环节	症状
采集进程（Poller）不足	采集队列 backlog 持续增长，数据点开始丢失
数据库写入	每秒写入量到几千，history 表写入成为瓶颈
单点网络	所有采集流量都从一个节点发出，跨子网时链路拥塞

第一条最容易观察到，也最容易被误判成"服务器性能不够"。实际上 backlog 增长意味着采集任务排不过来了，加 CPU 不一定有用，加 Poller 进程或者分摊采集才有效。

解法：按子网部署 Proxy

Zabbix 的 Proxy 是为这个场景设计的：采集任务下放到 Proxy，Proxy 在本地采集完、打包、按批上报给 Server。

        Zabbix Server（只做存储、告警、展示）
          ↑           ↑           ↑
      Proxy A      Proxy B     Proxy C
     （子网1）    （子网2）    （子网3）
       ↓            ↓           ↓
    设备群       设备群       设备群

收益是三层的：

1. 采集压力被切分。 每个 Proxy 只负责自己子网的设备，单个节点的采集负载降到原来的几分之一。

2. 网络流量本地化。 采集流量在子网内闭环，只有汇总数据跨网段上报。跨网段的流量大幅下降。

3. 故障域隔离。 某个 Proxy 挂了，只影响它管的那个子网，不会全站监控一起中断。这一点比性能提升更重要——监控系统自己不能成为单点。

用主动模式（Proxy 主动向 Server 拉取任务、主动上报数据）而不是被动模式，是因为主动模式下 Server 不需要主动连 Proxy，穿透防火墙容易，Proxy 侧也能靠缓冲队列扛住短时间的网络中断——断网期间数据先存本地，恢复后补传，不丢点。

监控项怎么从"一部分"到 400 项

400 余项不是一个个手加的，是按模板推的：

• 网络设备模板：端口状态、端口流量、CPU/内存、风扇电源、链路聚合状态
• 服务器模板：CPU、内存、磁盘、网卡、进程存活、系统负载
• 应用模板：数据库连接数、服务端口存活、关键业务接口状态

设备分组套模板，模板里定义监控项，加一台设备只需要挂到对应的组里。

这是"覆盖率 100%"这个数字的真实含义：不是每个设备都被人工盯过一遍，而是每台纳管设备都至少挂了一个模板，且模板里的关键项全部处于采集中。100% 覆盖率指的是"纳管设备 100% 有监控"，不是"100% 的指标都被监控"——这两者的区别，一旦有人核对就会暴露。

四、那四个数字的口径，得说清楚

量化指标最容易出问题的地方，是数字背后没有可核对的口径。"4 小时怎么算的"如果只能回答"大概感觉"，前面所有技术细节的可信度都会一起打折。

所以每个数字我都准备了口径：

MTTR：4 小时 → 15 分钟

定义：从"故障被感知"到"业务恢复"的时间。

改造前：故障靠用户报障。用户发现网络有问题 → 联系管理员 → 管理员到现场 → 判断是哪一段 → 逐台设备排查 → 定位 → 修复。这中间"用户发现"和"管理员到场"两段占了大部分时间，所以 4 小时里真正的技术排查可能只占 30 分钟。

改造后：监控告警在分钟内触发，告警内容直接指向具体设备和具体指标（"交换机 X 的端口 23 down"），排查从"猜"变成"看"。15 分钟主要是确认 + 处置的时间。

关键变化：省下的 3 小时 45 分钟里，绝大部分不是"修得更快"，而是"发现得更早、定位得更准"。 这个区别很重要——它说明改造的价值在可观测性，不在操作速度。

覆盖率 100%

口径：纳管设备中，处于监控采集状态的比例。计算方式是从控制器导出设备清单，跟 Zabbix 中有效采集中（非 unsupported）的主机做差集，差集为空。

不是："所有该监控的指标都监控了"。没有监控的东西还有很多——比如链路质量、无线信号覆盖、端口错包率。

告警响应效率提升 90%

口径：告警从产生到被人确认（ack）的平均时长。改造前依赖人工巡查和电话通知，平均确认时长以小时计；改造后接入消息推送，平均确认时长在分钟级，比值约提升 90%。

90% 这个数的算法是：(改造前平均确认时长 - 改造后平均确认时长) / 改造前平均确认时长。需要说明的是，它基于一段观测期内的告警记录统计，样本量有限，不是严格的 A/B 实验。

承认样本有限，比硬撑一个精确数字更可信。数据口径清楚、边界诚实，比数字好看重要得多。

五、做错的地方

只讲成果不讲失误，读起来就像宣传稿。三件事确实做错了：

1. 一开始想自己写采集。 曾考虑用 Python 直接 SNMP 采集再入库，理由是"灵活"。写到一半发现要处理的是轮询调度、数据去重、历史压缩、告警判定一整条链路——这些正是监控系统存在的意义。及时止损换用 Zabbix，是这次改造最正确的决定。

2. Proxy 部署顺序搞反了。 先在一个子网试点了 Proxy，觉得没问题就一次性推了全部子网。结果有一个子网的 Proxy 因为防火墙策略拿不到 Server 的地址，那个子网的监控静默了两天才被发现——监控系统自己失联，不会有任何人报警。

这件事之后加了一条规矩：Proxy 自身必须有独立的存活告警，且这个告警走另一条链路（比如 Proxy 心跳超时由 Server 侧判定，而不是 Proxy 自己上报）。监控不能自己监控自己。

3. 告警一开始设太密。 端口 up/down 全告警，一天几百条，很快就没人看了。后来改成只对关键端口告警，其余聚合。告警的有效性取决于数量，不取决于覆盖度——每天 500 条告警等于没有告警。

六、复盘

这次改造最值得带走的不是"会用 Zabbix"或"会配锐捷控制器"，而是三个判断方式：

1. 先定义事实来源，再谈工具。 资产清单让设备上报而不是人工维护，是所有后续工作的前提。事实不准，上层做什么都建在沙子上。

2. 改造的收益要能拆开归因。 MTTR 降了 3 小时 45 分，其中多少来自"发现更早"、多少来自"定位更准"、多少来自"处置更快"——拆开之后，才知道下一步该优化什么。

3. 监控系统的最大风险是它自己失联。 任何负责"发现问题"的系统，都必须有人在它出问题时发现它出问题。这条对所有可观测性建设都成立。

实验室的网络现在还在跑，控制器和监控都还在用。这套东西的价值不在于技术多新，而在于它把一个依赖人记忆和经验的系统，变成了一套可以被检查、被审计、被交接的系统——后来接手的人不需要再花半年摸清楚"这条线是怎么接的"。