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服务响应慢，都会导致命令执行超时。如果脚本没有超时处理机制，一旦某台设备卡住，整个批量任务就会僵在那里，后面的设备全部排队等待。

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

具体到Shell里，可以用timeout命令包装SSH会话，比如：

bash复制timeout 15 ssh admin@192.168.1.1 "show interface status"

如果15秒内命令没执行完，SSH会话会被强制终止，脚本继续往下走。这里超时时间的选择有讲究：太短容易误杀正常操作，太长又起不到熔断作用。根据我的经验，简单的查询类命令设10-15秒，配置类操作设30-60秒，具体要看设备实际响应速度。

2.4 日志留存：出了事能追溯，这才是保命关键

批量操作一定要留日志，而且要留得规范。每条命令执行的时间、设备IP、登录用户、执行内容、返回结果，全部记录下来。之前有一次变更出了故障，就是因为回调记录完整，才在半小时内定位到是哪条命令引发的路由振荡，及时做了回滚。

我习惯的项目结构是这样：

bash复制./batch_scripts/
├── logs/
│   ├── 2024-06-15/
│   │   ├── 192.168.1.1_config.log
│   │   ├── 192.168.1.2_config.log
│   │   └── batch_summary.log
├── configs/
│   ├── device_list.txt
│   └── interface_template.txt
├── lib/
│   └── common_functions.sh
├── batch_config.sh
└── monitor_network.sh

日志文件按日期和IP分类存放，每条操作都打上时间戳，出问题直接翻对应设备的日志，不用瞎猜。这个习惯帮我省了无数排查时间。

3. 实操过程与核心环节实现

3.1 批量配置网络设备：从设备清单到执行落地的完整链路

说了这么多思路，直接上干货。我封装了一套批量配置脚本，核心分三个文件：设备清单、公共函数库、执行入口。

设备清单采用简单的CSV格式，方便用Excel维护，也方便脚本解析：

csv复制device_ip,device_type,hostname,port
192.168.1.1,cisco_ios,core-sw-01,22
192.168.1.2,cisco_ios,core-sw-02,22
192.168.2.10,huawei_vrp,dist-sw-01,22
192.168.2.11,huawei_vrp,dist-sw-02,22

公共函数库common_functions.sh封装了SSH执行的核心逻辑，支持不同厂商设备的命令发送和回显抓取：

bash复制#!/bin/bash

run_ssh_command() {
    local device_ip=$1
    local username=$2
    local command=$3
    local timeout_sec=${4:-15}
    
    # 使用密钥认证，配合timeout防止卡死
    timeout "$timeout_sec" ssh -o StrictHostKeyChecking=no \
        -o ConnectTimeout=5 \
        -o BatchMode=yes \
        "${username}@${device_ip}" "$command" 2>&1
    
    local ret=$?
    if [ $ret -ne 0 ]; then
        echo "[ERROR] Command failed on $device_ip, exit code: $ret"
    fi
    return $ret
}

# 批量执行并记录日志
batch_execute() {
    local device_ip=$1
    local command=$2
    local log_file=$3
    
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] Executing on $device_ip: $command" >> "$log_file"
    local result=$(run_ssh_command "$device_ip" "admin" "$command")
    echo "$result" >> "$log_file"
    echo "$result"
}

执行入口脚本config_devices.sh按顺序做三件事：验证设备清单、逐台执行配置命令、生成汇总报告：

bash复制#!/bin/bash

source ./lib/common_functions.sh

DEVICE_LIST="configs/device_list.txt"
LOG_DIR="logs/$(date +%Y-%m-%d)"
SUMMARY_FILE="$LOG_DIR/batch_summary.log"
FAILED_DEVICES=()

mkdir -p "$LOG_DIR"
echo "===== Batch Config Start: $(date) =====" > "$SUMMARY_FILE"

# 这里用while read逐行读取CSV，跳过表头
while IFS=',' read -r device_ip device_type hostname port; do
    # 跳过注释行和空行
    [[ "$device_ip" =~ ^#.*$ || -z "$device_ip" ]] && continue
    
    echo "[INFO] Processing $hostname ($device_ip)..."
    
    # 按设备类型选择不同的配置命令集
    case "$device_type" in
        cisco_ios)
            COMMAND=$(cat <<'EOF'
configure terminal
interface GigabitEthernet0/1
description Uplink-to-core
no shutdown
end
write memory
EOF
            )
            ;;
        huawei_vrp)
            COMMAND=$(cat <<'EOF'
system-view
interface GigabitEthernet0/0/1
description Uplink-to-core
undo shutdown
return
save force
EOF
            )
            ;;
        *)
            echo "[WARN] Unknown device type: $device_type, skip $device_ip"
            continue
            ;;
    esac
    
    LOG_FILE="$LOG_DIR/${device_ip}_config.log"
    RESULT=$(batch_execute "$device_ip" "$COMMAND" "$LOG_FILE")
    
    if echo "$RESULT" | grep -qi "error\|invalid\|failed"; then
        echo "[FAIL] $hostname ($device_ip) error detected"
        FAILED_DEVICES+=("$device_ip")
    else
        echo "[OK] $hostname ($device_ip) configured successfully"
    fi
done < "$DEVICE_LIST"

# 输出汇总
echo "===== Batch Config Complete: $(date) =====" >> "$SUMMARY_FILE"
echo "Success count: $(($(wc -l < "$DEVICE_LIST") - ${#FAILED_DEVICES[@]}))"
echo "Failed devices: ${#FAILED_DEVICES[@]}"
for dev in "${FAILED_DEVICES[@]}"; do
    echo "  - $dev" >> "$SUMMARY_FILE"
done

这套脚本在实际项目里帮了大忙。有一次给全公司38台接入交换机统一开启端口安全策略，我用它在两分钟内完成了全部下发，而且每台设备的执行结果都留存了日志。搁在以前手工操作，至少得忙活一个下午。

3.2 监控网络状态：连通性、响应时间、资源利用率的自动化巡检

监控这块，我分成了三个层次：基础连通性监控、性能指标采集、异常告警通知。

第一层是基础连通性监控。这个最简单，用ping就能解决，但关键在于批量。我的做法是把所有需要监控的设备IP放进一个文本文件，然后用脚本批量ping，把结果整理成表格输出：

bash复制#!/bin/bash

# monitor_ping.sh - 批量ping检测
DEVICE_LIST="configs/monitor_list.txt"
ALIVE_COUNT=0
DEAD_LIST=()

while read -r device_ip; do
    [[ -z "$device_ip" || "$device_ip" =~ ^#.*$ ]] && continue
    
    if ping -c 3 -W 2 "$device_ip" > /dev/null 2>&1; then
        echo "[UP] $device_ip"
        ((ALIVE_COUNT++))
    else
        echo "[DOWN] $device_ip"
        DEAD_LIST+=("$device_ip")
    fi
done < "$DEVICE_LIST"

echo ""
echo "========== Ping Monitor Summary =========="
echo "Alive: $ALIVE_COUNT / $(wc -l < "$DEVICE_LIST")"
if [ ${#DEAD_LIST[@]} -gt 0 ]; then
    echo "Unreachable devices:"
    for dev in "${DEAD_LIST[@]}"; do
        echo "  - $dev"
    done
fi

但ping只能判断设备通不通，无法反映网络质量。所以我加了第二层——抓取设备的CPU利用率、内存使用率、接口流量等关键指标。这些数据可以通过SNMP协议获取，也可以用SSH执行show命令抓取。

如果设备支持SNMP，优先用snmpwalk，比SSH快得多，而且对设备CPU的消耗更小：

bash复制#!/bin/bash

# monitor_snmp.sh - 通过SNMP采集设备关键指标
COMMUNITY="public"
VERSION="2c"
CPU_OID=".1.3.6.1.4.1.9.9.109.1.1.1.1.8"   # Cisco设备CPU利用率
MEM_OID=".1.3.6.1.4.1.9.9.48.1.1.1.5"     # Cisco设备内存利用率

while read -r device_ip; do
    [[ -z "$device_ip" || "$device_ip" =~ ^#.*$ ]] && continue
    
    echo "===== Device: $device_ip ====="
    cpu_util=$(snmpwalk -v $VERSION -c $COMMUNITY -On "$device_ip" "$CPU_OID" 2>/dev/null | awk -F'"' '{print $2}' | tail -1)
    echo "CPU Utilization: ${cpu_util:-N/A}%"
    
    # 内存利用率通常要除以1024换算成百分比
    mem_raw=$(snmpwalk -v $VERSION -c $COMMUNITY -On "$device_ip" "$MEM_OID" 2>/dev/null | grep -o "[0-9]*$" | tail -1)
    if [ -n "$mem_raw" ]; then
        mem_util=$(echo "scale=2; $mem_raw / 1024" | bc)
        echo "Memory Utilization: ${mem_util}%"
    else
        echo "Memory Utilization: N/A"
    fi
done < "$DEVICE_LIST"

如果设备不支持SNMP，就得退回到SSH方式抓取show命令的回显。这里有个小小的技巧：很多设备支持在命令后加| include或| exclude做过滤，能大幅减少回显量，比如show process cpu | include CPU utilization，抓回来的数据干干净净，脚本处理起来也省事。

3.3 异常告警：让脚本学会“喊救命”

监控的目的不是看数据，而是发现问题。所以我给监控脚本加了一个告警模块：当某项指标超过阈值时，自动发送通知。

告警方式有很多种，最简单的就是用curl调用企业微信机器人或钉钉机器人的Webhook接口，直接推送到手机。我实测下来，这种方式最快最稳定，比发邮件靠谱多了，手机上能看到通知，下楼喝个咖啡的空档都不会漏掉重要告警。

还是用刚才的CPU监控举例，在脚本里加入阈值判断：

bash复制#!/bin/bash

# alert_cpu.sh - CPU告警监控
source ./lib/common_functions.sh

THRESHOLD=85
WEBHOOK_URL="https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY"

send_alert() {
    local device_ip=$1
    local cpu_value=$2
    local message="{\"msgtype\": \"text\", \"text\": {\"content\": \"[告警] 设备 $device_ip CPU使用率达到 ${cpu_value}%，请及时处理！\"}}"
    
    curl -s -H 'Content-Type: application/json' \
        -d "$message" \
        "$WEBHOOK_URL" > /dev/null
}

check_cpu_load() {
    local device_ip=$1
    local cpu_util
    
    cpu_util=$(get_snmp_cpu "$device_ip")
    if [ -n "$cpu_util" ] && [ "$cpu_util" -ge "$THRESHOLD" ]; then
        echo "[ALERT] $device_ip CPU high: $cpu_util%"
        send_alert "$device_ip" "$cpu_util"
    else
        echo "[INFO] $device_ip CPU normal: ${cpu_util:-N/A}%"
    fi
}

while read -r device_ip; do
    [[ -z "$device_ip" || "$device_ip" =~ ^#.*$ ]] && continue
    check_cpu_load "$device_ip"
done < "configs/monitor_list.txt"

这样配置好，配合crontab定时任务，每5分钟跑一次，全网设备的CPU状态就在掌控之中了。某台设备CPU飙高，告警消息会在30秒内推送到微信，基本能做到故障未感知、告警先到。

3.4 crontab定时调度：把监控变成“永不停歇的哨兵”

Shell脚本本身是一次性的，但配合Linux系统的crontab，就能变成全天候自动巡检的守护神。我的定时策略很简单直接：

bash复制# 每5分钟检查一次设备连通性
*/5 * * * * /opt/network_scripts/monitor_ping.sh >> /var/log/network_monitor.log 2>&1

# 每10分钟采集一次性能指标
*/10 * * * * /opt/network_scripts/monitor_snmp.sh >> /var/log/network_monitor.log 2>&1

# 每天凌晨2点批量备份设备配置
0 2 * * * /opt/network_scripts/backup_configs.sh >> /var/log/network_backup.log 2>&1

# 每天早晨8点生成巡检报告
0 8 * * * /opt/network_scripts/generate_report.sh

这里要注意一个问题：crontab的环境变量和交互式终端不一样，PATH路径可能不完整。脚本里如果用了绝对路径，问题不大；但如果依赖了某些不在系统默认PATH里的命令（比如自己装的snmpwalk），最好在脚本开头显式设置PATH，或者直接用命令的绝对路径，否则crontab跑起来会报“command not found”，排查一个晚上都找不到原因。

4. 常见问题与排查技巧实录

4.1 SSH连接卡住不动，脚本仿佛“死机”了

这个问题早年困扰了我很久。脚本跑着跑着，某一台设备就卡住了，既不报错也不往下走，整个批量任务被它拖在那里。

后来排查发现，罪魁祸首是设备SSH网关的Banner信息——有些设备登录时会打一大段ASCII艺术字横幅，然后才跳转到正常提示符。我的expect脚本或SSH批量命令没有处理这段多余输出，程序在等待匹配提示符时就陷入了永久等待。

解决方案有两个：一是用ssh -T参数禁用伪终端分配，减少不必要的交互回显；二是使用-o ConnectTimeout和timeout命令双保险，确保任何情况下都不会无限期等待。实在不行，还可以通过-o ServerAliveInterval=30设置SSH心跳包，避免长连接被中间设备静默丢弃。

4.2 不同厂商设备的命令差异太大，脚本怎么写才能通用

华为、思科、H3C、锐捷，每家厂商的命令风格差异很大。比如思科是show interface status，华为却要用display interface brief；思科保存配置是write memory，华为是save force。写脚本时如果把这些命令全部写死在代码里，换一批设备就得从头改。

我用的方法是建立一个配置文件，把不同厂商的命令差异全部外置到配置文件里。命令词条按厂商分类，脚本运行时根据设备类型去查表，执行对应的命令：

bash复制# configs/command_map.conf
# 格式: 操作类型|厂商|命令
SHOW_INTERFACE|cisco_ios|show interface status
SHOW_INTERFACE|huawei_vrp|display interface brief
SAVE_CONFIG|cisco_ios|write memory
SAVE_CONFIG|huawei_vrp|save force

脚本读取这个配置文件，根据目标设备的厂商类型拼装出完整的命令链，从而让一套脚本兼容多厂商设备。这个改造花了我一个下午，但后续维护脚本的效率提升了好几倍。

4.3 批量操作中部分设备失败，如何快速定位重试

批量脚本最大的痛点是“全都跑了，但不知道哪几台成功、哪几台失败”。如果汇总报告没做好，你还得手动去翻每一台设备的日志。

我习惯在脚本里维护一个失败队列，凡是执行失败的设备IP全部记录下来，最后统一打印出一份“失败清单”，并且自动生成一个重试脚本。这样一次批量操作完成后，我只需要盯着失败清单看，哪些设备需要人工介入、哪些设备只是临时网络抖动、重试就能成功，心里清清楚楚。

这里有个容易被忽略的细节：失败重试时，要注意命令是否已经执行了一半。有些网络设备对配置命令是“逐条生效”的，如果脚本在第一条命令成功后、第二条命令前中断，重试时就要考虑幂等性处理——要么先回滚到初始状态，要么确保命令本身设计成“重复执行也不会报错”的幂等形式。

4.4 常见问题速查表

我整理了这份速查表，都是实操中高频踩坑的点，各阶段运维都用得上。

5. 我在实际维护中的几点体会

这套Shell运维体系我在生产环境里跑了快两年，最大的感触是：自动化不是目的，把重复劳动省下来去处理真正重要的事才是目的。

刚开始搭批量配置脚本的时候，我总想着把所有功能都做进去——交互式菜单、彩色输出、复杂的参数解析。后来被现实教育了几次才明白，运维脚本的第一原则是简单可靠。一个几百行的“豪华”脚本，远不如几个几十行的“短小精悍”脚本好用。短脚本容易审查、容易修改、出问题一眼就能定位，长脚本看着很酷，但维护成本会让你的头发少得很快。

另外想提一点：脚本里的注释一定要写清楚“为什么这么做”，而不是“做了什么”。半年后你再回来看自己写的脚本，ssh -o BatchMode=yes这行代码你当然知道是干嘛的，但你可能完全不记得当时为什么要加这个参数——因为某次批量操作时设备换过主机名导致指纹校验失败，那次故障排查花了大半夜。把这种背景写进注释，后面接手的人才能真正理解你的设计意图。

监控脚本的告警阈值设置也不要一味追求“灵敏”。阈值太敏感，天天告警，大家就会自动忽略告警；阈值太宽松，出了问题没人知道，监控形同虚设。我的经验是先跑一周观察正常基线，把正常波动范围摸清楚，再在基线基础上留出20%-30%的余量设置告警阈值。比如正常CPU基线是30%-50%，告警阈值就可以设在85%左右，既能排除小波动干扰，又能在真正异常时及时曝光。

这套东西扩展性也很好。今天写的是批量配置和连通性监控，明天可以加上配置备份、合规审计、流量分析。我现在正在做的一件事是给这套脚本加一个Web前端，通过网页就能手动触发配置下发、查看监控报表，省去了每次都要登服务器敲命令的麻烦。Shell脚本在这里依然扮演核心引擎的角色——前端只是换了个壳，真正干活的还是那些经受过无数次考验的老伙计。

最后再分享一个小经验：运维脚本不要只在自己的电脑上测试两遍就丢到生产环境，要建一个独立的测试环境，把设备模拟器搭起来，新脚本先在模拟环境里跑几轮，确认没有副作用了再上生产。这个习惯帮我拦下了至少三次可能导致线上事故的低级错误，代价不过就是每天多花20分钟做测试，这笔账怎么算都值。