15827631206
行业动态 更多+
联系我们 / CONTACT
网络工程师进阶指南：如何制定网络设备巡检表与实现自动化脚本化
作为一名网络工程师，你是否经历过这样的场景：明明昨天网络还“风平浪静”，今天突然有用户投诉网速慢，一查发现某条关键链路早在三天前就已经出现了大量的 CRC 错误包？或者某台核心交换机风扇故障，温度飙升导致性能抖动？
网络设备的故障往往具有“隐蔽性”和“累积性”。“盲人摸象”式的巡检（只看灯亮不亮，或者只 Ping 一下通不通）早已无法满足现代网络运维的要求。
今天我们来聊聊如何建立一套科学的网络设备巡检表，并将其转化为自动化脚本，让网络隐患无处遁形。
第一部分：制定“黄金”网络巡检表
网络设备的巡检表不能是流水账，它必须是一个“体检套餐”。我们需要从物理层到应用层，逐级拆解。
1. 基础环境与硬件层（物理健康）
网络设备首先是硬件，硬件故障是致命的。
环境检查： 设备面板温度、风扇转速状态、电源模块状态（是否双电冗余）。
光模块/端口状态： 是否有
Link Flap（链路震荡）？光模块收发光功率是否在阈值范围内（这点常被忽略，光衰过大是丢包元凶）。
2. 系统资源层（大脑健康）
虽然网络设备专用性强，但 CPU 和内存依然是瓶颈。
CPU/Memory 利用率： 重点关注是否长时间超过 70%-80%（不同品牌阈值不同）。
会话数/NAT 表： 防火墙特别关注，会话数爆满会导致新建连接失败。
3. 二层与三层网络层（道路通畅度）
这是网络工程师最核心的关注点。
端口流量与错误包：
接口
Input/Output Errors、CRC Errors、Discards。如果有计数增长，说明链路质量有问题（网线老化、光模块脏、速率双工不匹配）。带宽利用率是否触及端口上限。
生成树 (STP) 状态： 根桥位置是否正确？是否有频繁的拓扑变更（TCN）？
路由协议： OSPF/BGP 邻居关系是否 Full？路由表条目数量是否异常激增？
4. 日志与安全层（病历本）
Log 日志： 是否有
Error级别以上的告警？如板卡插拔、端口 Down、认证失败。配置变更： Startup-config 与 Running-config 是否一致？（防止重启后配置丢失）。
附：网络设备巡检表模板（示例）
| 检查维度 | 检查项 | 检查命令参考 | 正常标准 | 风险等级 |
|---|---|---|---|---|
| 硬件 | 设备温度 | show environment | 温度 < 45℃ (视型号定) | 高 |
| 硬件 | 电源状态 | show environment power | Status: Normal | 高 |
| 资源 | CPU利用率 | show cpu / show processes cpu | < 60% | 中 |
| 端口 | 接口错误包 | show interface | CRC/Errors = 0 | 高 |
| 端口 | 光模块功率 | show transceiver detail | 功率在厂商建议范围内 | 中 |
| 协议 | OSPF邻居 | show ip ospf neighbor | 状态为 Full | 高 |
| 配置 | 配置一致性 | compare startup running | 无差异 | 中 |
第二部分：从 CLI 到 Python——巡检脚本化实战
网络设备的一大特点是厂商众多（Cisco、Huawei、H3C、Juniper），命令行各异。传统的 Shell 脚本很难统一处理，因此Python 成为了网络自动化巡检的最佳工具。
1. 技术选型：Python + Netmiko
不要去用复杂的 Ansible（对于简单巡检来说太重），也不要用原始的 Telnet 库。推荐使用 Netmiko 库，它基于 Paramiko 开发，专门针对网络设备做了优化，支持多厂商，自动处理分页（more）和延时问题。
2. 脚本设计思路
设备清单管理： 从 Excel 或 CSV 文件读取 IP、用户名、密码、设备类型。
命令执行： 循环登录设备，下发巡检命令。
关键数据提取（核心）： 这是最难的一步。拿到回显文本后，用正则表达式提取关键指标（如 CPU 数值、Error 计数）。
判断与告警： 将提取的数据与阈值比对，异常则输出或发邮件。
3. 实战代码片段（简化版）
这是一个使用 Python netmiko 库巡检 Cisco/Huawei 设备 CPU 和端口错误包的简易脚本逻辑：
from netmiko import ConnectHandler import re # 定义设备信息 device = { 'device_type': 'cisco_ios', # 或 'huawei', 'hp_comware' 'host': '192.168.1.1', 'username': 'admin', 'password': 'password', } def check_network_device(device): try: # 建立连接 net_connect = ConnectHandler(**device) # --- 1. CPU 检查 --- # Cisco 命令: show processes cpu # Huawei 命令: display cpu output_cpu = net_connect.send_command("show processes cpu | include CPU") # 使用正则提取 CPU 百分比 (示例: "CPU utilization for five seconds: 15%") cpu_match = re.search(r'(\d+)%', output_cpu) if cpu_match: cpu_usage = int(cpu_match.group(1)) if cpu_usage > 80: print(f"[告警] {device['host']} CPU过高: {cpu_usage}%") else: print(f"[正常] {device['host']} CPU: {cpu_usage}%") # --- 2. 接口错误包检查 --- output_int = net_connect.send_command("show interface counters errors") # 这里逻辑较复杂，简化为判断输出是否包含非0数字 # 实际生产中需逐行解析 input_error, output_error, crc net_connect.disconnect() except Exception as e: print(f"[失败] 连接 {device['host']} 异常: {e}") # 实际应用中，这里循环读取CSV文件列表 check_network_device(device)
4. 进阶：如何处理多厂商？
你可能会问：“Cisco 是 show，华为是 display，怎么写通用的？”
建议采用“命令映射字典”的方法：
COMMANDS = { 'cisco_ios': { 'cpu': 'show processes cpu', 'version': 'show version' }, 'huawei': { 'cpu': 'display cpu-usage', 'version': 'display version' } } # 在脚本中根据 device_type 调用 cmd = COMMANDS[device['device_type']]['cpu'] output = net_connect.send_command(cmd)
第三部分：网络巡检的“避坑”与演进
脚本化只是第一步，在网络巡检的落地过程中，还有几个关键点需要注意：
1. 警惕“瞬时值”陷阱
很多工程师巡检只看当前 CPU。但网络流量是突发的，此时 CPU 正常，下一秒可能就飙升。
改进方案： 巡检脚本可以循环执行 3 次，每次间隔 5 秒，取平均值，或者结合 Zabbix/Prometheus 等监控系统的历史数据（如 1 小时平均最大值）来判断，比单次巡检更准。
2. 关注“计数器”的增量
show interface 看到的错误包计数往往是设备启动以来的累计值。如果一台设备运行了 5 年，有几个错误包是正常的。
改进方案： 脚本需要记录上一次巡检的值，计算差值。如果 1 天内增加了 1000 个 CRC 错误，那这条链路必须排查。
3. 从“脚本”到“平台”
当设备量超过 100 台时，单纯跑脚本看日志也很累。建议：
输出 HTML 报告： 使用 Python 的
PrettyTable或Jinja2模板，生成一份带颜色（红色异常、绿色正常）的网页报告，每天早上自动发送邮件。对接 NMS： 既然做了脚本，不如把数据存入 InfluxDB，用 Grafana 画出“网络健康大屏”。
结语
网络设备的巡检，不仅仅是看“通不通”，更是看“稳不稳”。
制定巡检表是梳理网络逻辑的过程，而编写巡检脚本则是将逻辑固化为生产力的手段。从 show logging 到 Python 自动化，这不仅是技术的升级，更是运维思维的转变——从“救火队员”转变为“保健医生”。
希望这篇文章能为你构建网络自动化巡检体系提供参考！