Shell脚本实战：批量配置网络设备与状态监控

接到一个很有意思的活儿：用 Shell 批量配置网络设备、顺带把网络状态监控也一块儿做了。这标题乍看像是老网工的日常，但真要动起手来，里面全是细节和坑。我自己在项目里被几十台交换机挨个手工敲命令搞到崩溃之后，才老老实实把 Shell 脚本这套东西捡起来重新捋了一遍。今天这篇就把我实际用到的东西——从最基础的框架、到批量下发配置、再到状态监控和问题排查——完整复盘一遍。

先说一个基本判断：Shell 处理网络设备批量操作，真正好用的地方不是它功能多强，而是它“刚好够用”。网络设备大多支持 SSH 连接，Shell 天生就是和命令行打交道的，再加上系统自带，不需要额外安装重型依赖，在跳板机、运维堡垒机上几乎开箱即用。你当然可以用 Python + Paramiko 写一套更优雅的框架，但很多场景下，一个 50 行的 Shell 脚本就能搞定，没必要杀鸡用牛刀。

这篇文章适合谁？正在被“一台台设备手工刷配置”折磨的初级运维，想把手头重复性网络操作脚本化的工程师，以及准备在团队里推广自动化网络操作、但还没想好从哪个点切入的朋友。如果你已经用 Ansible 管理网络设备，这文里的思路也能帮你理解它底下那层逻辑是怎么转的。

1. 先想清楚：为什么是 Shell，而不是 Ansible 或者 Python

1.1 网络设备批量操作的真实痛点

先还原一下场景。假设你手头有 30 台接入层交换机，需要统一把 NTP 服务器地址改掉，或者统一开启 RSTP、调整链路聚合参数。如果一台一台登上去敲命令，按每台 5 分钟算，一个半小时就没了，这还不算中间被人打断、敲错命令、设备登录超时这些意外。

更麻烦的是误操作。手工模式下，你很难保证每台设备的输入完全一致。我那会儿就出过岔子：有两台交换机的 VLAN 配置被我手误敲错了，业务上线当天就出现二层环路，差点酿成事故。从那以后，凡是超过 5 台设备的统一变更，我坚决不再手工逐台操作。

批量操作的价值不只是省时间。它真正解决的是“一致性”——同样的配置，用同样的命令，在同一时间点下发，结果可预期，出错可回查。这些都是手工模式给不了的。

1.2 Shell 在“轻量批量”场景里的独特优势

Shell 这个选择，核心是“轻”。它不像 Ansible 那样需要额外的控制端环境、Python 依赖和设备端 Python 解释器，也不像 Python 脚本那样要考虑运行环境、第三方库、异常处理框架。你只要有一台 Linux 机器，装上 openssh-client，再加一个顺手的 expect 或 sshpass，就能开始干活。

我把日常批量运维拆分成了几个动作：连设备、发命令、收结果、做判断。这四个动作里，Shell 有天然的处理优势。比如批量循环设备列表，一个 for 循环就行；结果抓取后用 grep 和 awk 过滤关键字段，那更是 Shell 的看家本事；最后用重定向把结果落盘归档，不需要引入任何额外工具。

And 再一个关键点：Shell 脚本本身就是“所见即所得”的。发给设备的命令在脚本里写得很直白，评审的人一眼能看懂在干嘛。相比之下，用 Python 写一套封装好的 netmiko 调用，可读性反而不如纯 Shell 脚本直接。

1.3 边界意识：哪些场景不该硬上 Shell

Shell 不是万能的。我踩过几次坑之后，总结出几条“硬上会翻车”的场景：

• 需要同时操作几百台设备，且要处理大量并发回显时。Shell 的并发处理能力弱，xargs -P 能解决一部分，但输出交错、资源竞争会让人头疼。
• 需要解析设备返回的复杂结构化数据，比如用 SNMP 抓一张大表做关联分析。这是 Python 或专业网管系统的活儿。
• 需要在多厂商设备之间做复杂的命令差异转换。虽然可以通过函数封装适配，但配置多了会非常难维护。

所以我的选型原则是：10 到 60 台设备、操作内容相对单一、以配置下发生效为主的场景，Shell 就是最优解。 超过这个规模，或者追求更完善的重试、回滚机制，我可以随时换用 Python 重写同一套逻辑，Shell 版脚本本身就相当于需求文档和验证原型。

2. 批量操作前的准备工作：环境、账号与设备清单

2.1 最小化环境清单

动手写脚本之前，先把环境配好。我建议的最小环境是：

• Linux 操作系统的跳板机（我用的是 Ubuntu 22.04，但其实任何发行版都行）
• 安装 sshpass（非交互式密码认证用）或者 expect（更可控的交互式会话工具）
• 能连通所有目标网络设备的网络路由
• 一个可以存放脚本和日志的目录，比如 /opt/netops/

安