Shell脚本实战：批量配置网络设备与自动化监控运维指南

半夜两点被值班电话叫醒，说分公司核心交换机CPU飙到90%，所有办公电脑上网卡成幻灯片。我爬起来先ping网关，通了，延迟却高得离谱。SSH登上去一看，满屏日志刷得飞快，广播风暴在VLAN里横冲直撞。这种时候你就会发现，手里要是没几个趁手的Shell脚本，光靠手工敲命令一条条排查，天亮都搞不定。

干网络管理员这行，Shell不是选修课，是保命技能。从日常巡检到故障溯源，从批量下发配置到全网状态监控，Shell几乎贯穿了每一个运维场景。今天就拿我实际维护的一套脚本体系做例子，聊聊怎么用Shell批量配置网络设备、监控网络状态，把那些重复、繁琐、容易手滑的操作，全部变成自动化流水线。

1. 内容整体设计与思路拆解

1.1 网络管理员的真实痛点：不是命令不会敲，是量太大

先说个扎心的事实：考证时背得滚瓜烂熟的配置命令，真正走进机房才发现根本不顶用。单台设备怎么配、怎么查，教程里写得清清楚楚，但现实是——你要面对的是几十台上百台设备，每台设备的配置可能还有细微差异，端口状态要挨个确认，VLAN要逐条核对，ACL策略要反复比对。

靠人肉一台台SSH上去敲命令？可以，但效率低到令人发指，而且极易出错。手一抖把接口写错，可能就是一次全网断网事故。

我见过太多刚入行的同事，拿着Excel表格挨个记设备IP，然后用SecureCRT开十几个标签页，一台台登录、一条条敲命令。遇到设备登录超时、命令回显卡顿，整个人就懵了。这种工作方式，一晚上能处理完30台设备都算快的，而且第二天脑袋完全是蒙的，根本回想不起来昨天到底改了什么。

1.2 为什么选Shell而不是Python或Ansible

可能有朋友会问，现在自动化运维不是都在讲Python、讲Ansible吗？为什么还在用Shell？

我的回答是：都可以，但Shell是不可替代的底座。

Python和Ansible当然强大，但它们有一个共同的问题——需要额外安装依赖、配置环境。你出去处理故障，进入客户的机房，面对的可能是各种老旧设备，甚至是离线环境。这个时候，系统自带的Shell就是你唯一能依靠的武器。它是Linux系统的原生组件，不需要装任何东西，只要有SSH客户端就能干活。

另外，Shell在文本处理上有天然优势。网络设备的命令回显基本都是文本格式，用Shell的grep、awk、sed处理起来行云流水，比Python的字符串操作更直观。真的只是想把几十台设备的接口状态、CPU利用率、日志关键字抓下来，Shell绝对够用，而且脚本写起来短小精悍，改起来也方便。

当然，我团队里也会用Ansible做配置下发，但它更多是作为“重武器”用在规范化场景，日常的快速排查、临时变更、告警响应，我还是习惯用Shell脚本来兜底。

1.3 核心思路：一台设备会配，就让它替你在所有设备上执行

Shell批量配置网络设备的逻辑，说白了就一句话——把你在一台设备上敲的那些命令，封装成可复用的脚本，然后通过循环、并发、异常处理机制，让它在所有目标设备上自动执行。

这个思路的本质是“模板化+批量化”。你需要做的核心工作有三件事：

第一，理清设备清单。哪些设备需要执行哪些命令，IP地址是多少，登录凭据是什么（这里强烈建议用密钥认证）。这些信息整理成结构化的文本或CSV文件。

第二，封装单台设备的操作。把登录、执行命令、抓取回显、退出这整套流程，写成函数或模块。这是整个体系的基础，一定要保证它足够健壮。

第三，设计执行策略。是逐个执行还是并发执行？超时怎么处理？失败要不要重试？告警怎么通知？这些问题想清楚了，脚本才不会在关键时刻掉链子。

监控网络状态也是一样的思路。你平时巡检时看的那些指标——连通性、丢包率、接口流量、CPU利用率、日志报错——全部可以转换成Shell脚本定时抓取，生成结果文件，然后通过简单的判断逻辑决定是否触发告警。

2. 核心细节解析与实操要点

2.1 连接与认证：别再用明文密码硬怼了

批量操作第一个要解决的问题就是连接认证。早期我犯过一个大错——把密码直接写在脚本里，结果脚本文件被一个临时工拷走，全网的密码瞬间泄露。那次之后我做了两个改变：

一是尽量使用SSH密钥认证。在跳板机上生成一对密钥，把公钥分发到所有网络设备的授权用户下。这样脚本里完全不需要出现密码，安全性大幅提升。

二是如果实在要用密码认证（有些老旧的网络设备不支持密钥），那就用expect脚本配合环境变量传递密码，脚本本身通过安全渠道传输，用完之后立即销毁。

这里要特别强调一个细节：expect的交互匹配很容易踩坑。网络设备的登录提示符五花八门，有的是"Password:"，有的是"password:"，大小写敏感。建议在匹配时用不区分大小写的写法，或者在expect语句里把可能的提示符都列出来，否则脚本很容易莫名卡住。

2.2 并发控制：别把设备搞崩了

批量操作最大的坑就是并发数没控制住。我曾经写过一版脚本，用for循环把所有设备丢到后台并发执行，结果有台老旧的接入交换机直接卡死，最后只能跑一趟现场硬重启。

后来我学乖了：并发控制必须做，而且要做得精细。Shell里控制并发常用三个工具：wait配合后台任务、xargs -P参数、mkfifo命名管道实现令牌桶。

我的建议是优先用xargs -P，因为它最简单，参数控制也清晰。比如一次最多同时处理10台设备：

bash复制cat device_list.txt | xargs -P 10 -I {} ./config_one.sh {}

这种写法把并发数限制在10个以内，既不会把设备压垮，也不会因为串行执行导致整体耗时太长。实测下来，50台设备批量下发配置，并发10个，整个过程控制在3分钟以内，比手工快了一个数量级。

2.3 超时与重试：让脚本自己学会“认怂”

网络环境永远是不可靠的。设备负载高、网络拥塞、SSH服务响应慢，都会导致命令执行超时。如果脚本没有超时处理机制，一旦某台设备卡住，整个批量任务就会僵在那里，后面的设备全部排队等待。

处理方案很简单：给每个操作设置合理的超时时间，超时就放弃这台设备，记入失败清单，继续处理后面的设备。等主体任务跑完，再单独对失败清单做重试。

具体到Shel