上周三下午，公司视频会议突然卡顿，IT小张查了半小时才定位到是核心交换机的端口错包率飙升。等他填完故障单、发完邮件、再补录系统日志，已经快下班了——结果发现漏写了维护动作的具体时间点和回滚步骤，第二天又被主管叫去重新补录。
别让记录变成负担
网络维护记录不是交差材料，而是故障复盘、责任追溯、新人上手的第一手依据。写得太简，下次出问题没人看得懂；写得太散，翻半天找不到关键信息。我们日常用的模板，就长这样：
1. 基础信息栏（必填）
日期｜时间（精确到分钟）｜记录人｜涉及设备/系统（例：HR部门VLAN20、出口防火墙FW-01）
2. 问题现象（用眼睛和工具看到的）
✔ 不写“网络慢”，写“OA登录响应超时＞15s，ping网关丢包率37%”
✔ 不写“连不上”，写“无线SSID ‘Office-Guest’ 无法获取IP，DHCP服务器日志显示地址池耗尽”
3. 处理过程（谁、在哪儿、干了啥）
按时间线列清楚，避免“检查配置”“重启服务”这类模糊描述：
• 14:22 登录核心交换机SW-01，执行 show interfaces gi1/0/5，发现CRC错误计数持续增长
• 14:28 更换该端口网线，错误计数停止上升
• 14:35 在接入层交换机SW-03对应端口执行 shutdown → no shutdown
4. 验证结果（必须有闭环）
✔ “会议系统恢复正常，连续10分钟抓包无重传”
✔ “员工反馈WiFi已可连接并上网，随机抽测5台终端DNS解析正常”
5. 后续建议（可选但很关键）
• 网线老化，建议Q3前更换楼层弱电间全部Cat5e跳线
• DHCP地址池剩余不足10%，需扩容或启用地址回收策略
一个真实模板示例
以下是我们内部用的纯文本模板，复制粘贴就能改：
【日期】2024-06-12 【时间】09:15-09:48 【记录人】李工 【设备】出口路由器RT-01、财务部子网10.20.30.0/24
【现象】财务ERP系统无法访问外网API，telnet至API端口超时；同网段其他业务正常。
【处理】
• 09:18 查RT-01路由表，发现10.20.30.0/24的NAT转换条目缺失
• 09:22 进入ACL配置视图，确认财务VLAN未被加入NAT策略组
• 09:25 执行命令：access-list 101 permit ip 10.20.30.0 0.0.0.255 any；ip nat inside source list 101 interface GigabitEthernet0/1 overload
• 09:27 保存配置并写入startup-config
【验证】财务主机curl -I https://api.xxx.com 返回HTTP/1.1 200 OK，持续测试5分钟无异常。
【建议】所有业务VLAN应在上线前统一纳入NAT策略基线检查清单。模板不是框死的，重点是：时间准、动作实、结果可验。你填一次，后面查三次，值回十倍时间。