简介这是一份面向运维人员及初学者的Shell脚本实战合集以PDF文档形式整理了279个开箱即用的脚本案例聚焦攻击防护、系统告警、数据库备份与日志分析等高频运维场景。内容包含攻击来源自动屏蔽、系统邮件告警配置、数据库单循环与多循环备份、Web日志按天切割与访问分析、网卡实时流量查看等典型需求每个脚本均配有思路说明和关键命令拆解覆盖文本处理、正则匹配、防火墙策略、定时任务等场景的常用命令组合与排查思路。通过对照学习读者既能理解自动化运维的整体流程也能直接修改参数部署到自己的服务器环境中节省日常排查和重复操作的时间。资源包共1个文件类型为PDF大小约4.69MB便于本地查阅、打印或反复学习。目前已有154人浏览学习适合希望提升Shell编程能力、构建服务器监控与备份体系的运维新手和中级工程师使用。1. 279个开箱即用的shell脚本为什么我建议你拿到手先别急着跑如果你是刚走完 shell脚本入门 阶段看到279个开箱即用的shell脚本2024年新版这种资源第一反应多半是下载下来、chmod x、然后挨个跑——我当年也这样结果大半脚本在报错。所谓开箱即用是作者在固定环境下的说法换到你的机器上bash版本、外部命令、路径习惯都会让箱子打不开。这个标题实际讲的是一份成体系的shell脚本合集覆盖系统巡检、日志清理、备份、网络检测等运维杂活它的价值不只是省时间更是给想提升 shell脚本基础知识 的人一批真实可读的样本。适合三类人被重复性运维工作压得喘不过气的工程师想用现成脚本垫脚入门的新手以及想把自己散落的脚本沉淀成工具箱的人。拿到手之后正确的玩法不是急着跑而是按场景分类、改造成自己的东西。2. 从279个脚本里选对场景按用途分类与选型逻辑2.1 系统巡检类先看脚本里用没用到外部命令系统巡检脚本是这个合集里最实用的部分通常包含 CPU 负载、内存占用、磁盘水位、登录失败次数等检查。但开箱即用不代表跨平台free -m在 CentOS 7 和 Ubuntu 22.04 的输出格式不一样df -h在部分精简系统上不显示 tmpfsss和netstat更是新旧交替。拿到脚本的第一步不是运行而是检查它依赖哪些外部命令。我习惯先跑一条命令grep -hoE \b(awk|sed|grep|free|df|ps|top|ss|netstat|iostat)\b check_sys.sh | sort -ugrep -h表示不打印文件名-o只输出匹配到的单词-E启用扩展正则\b是单词边界。这样能在一秒内列出脚本用到的外部命令。然后把结果逐个用command -v验证for cmd in $(grep -hoE \b(awk|sed|grep|free|df|ps|top|ss|netstat|iostat)\b check_sys.sh | sort -u); do command -v $cmd /dev/null || echo 缺失: $cmd done好的巡检脚本会主动规避外部命令差异例如直接读取/proc/meminfo而不是依赖free使用find而不是du遍历大目录。选型时我优先挑这种自包含程度高的脚本——它们即使脱离作者的环境也能跑出合理结果。另一个选型标准是看脚本是否考虑过非交互执行。很多人把巡检脚本塞进 cron结果脚本里面用了交互式readcron 会直接跳过或者挂住。grep 一下有没有read、tput、clear这类交互命令grep -nE \b(read|tput|clear|stty)\b check_sys.sh有的话要么改掉要么只在终端里手动跑。还有一点巡检脚本的退出码很重要。如果脚本的目的是发现问题那它应当在异常时返回非 0这样你才能用 cron 的 MAILTO 或监控系统抓到告警。很多脚本结尾只写echo check done然后无条件exit 0这类脚本当参考样例可以直接接入监控就要小心。对于新手来说从这种合集里选巡检脚本不要贪图功能多先选能看懂、依赖少的等理解后再切换到更复杂的版本。2.2 日志处理与备份类通配符、保留期限与退出码日志清理脚本是合集里的另一大分类也是最容易开箱即翻车的。常见功能是删除 N 天前的.log文件、压缩归档、备份数据库等。这里第一个坑是通配符脚本里写rm -f /var/log/app/*.log当目录里没有任何 .log 文件时bash 会把字面量*.log传给 rmrm 报No such file or directory但如果你用的是rm -rf加上-f就会静默失败日志里什么都看不到。更稳妥的做法是用 find 来匹配文件名# 清理 LOG_DIR 下超过7天的日志删除前先打印 LOG_DIR${1:-/var/log/app} find $LOG_DIR -type f -name *.log -mtime 7 -print -delete这里-type f避免误删目录-mtime 7表示修改时间超过 7 天-print先打印路径再-delete方便第一次运行时审查。把7改成30就是保留一个月参数化更好KEEP_DAYS${2:-7}然后find $LOG_DIR -type f -name *.log -mtime ${KEEP_DAYS}。注意-mtime 7的语义是大于 7*24 小时和 Java 里lastModified严格小于某个时间点是等价的但如果你需要7 整点的精确边界用-mmin更直观。备份脚本的选型要点是是否检查每一步的退出码。数据库备份用mysqldump时管道到 gzip 再传走任何一个环节失败都应该让脚本停下并告警。许多合集脚本只检查最后一个命令的$?这是不够的。你可以先跑一次故意把目标目录改成只读观察脚本是否报错也可以用set -euo pipefail让脚本在出错时直接退出——但pipefail在 bash 3.x 里不可用这一点后面避坑章会展开。日志脚本另一个常被忽略的点是对文件名本身含时间的格式是否敏感。比如app-20240101.log用-mtime清理没问题但如果想按文件名日期删除得用date -d做时间换算那就依赖 GNU datemacOS 上是跑不了的。所以选型先看脚本开头有没有#!/bin/bash再看它有没有用date -d、sed -i这类非 POSIX 特性。这也是 shell脚本基础知识 里最容易混淆的部分不是所有 linux 命令的选项都长得一样。2.3 网络检测类脚本ping 通不等于服务可用第三类常见脚本是网络连通性检测用于机房巡检或监控前置检查。大部分新手拿过来直接看ping结果但 ping 只能确认 ICMP 通不能确认某个端口的 TCP 服务在监听。真正的服务可用性检测至少要看 TCP 端口或 HTTP 状态码。合集中如果有用curl做健康检查的脚本注意它是否设置了超时——没设超时的 curl 遇到网络黑洞时会一直挂着cron 里就会堆积僵尸进程。我一般会改成这种写法check_http() { local url$1 local code code$(curl -o /dev/null -s -w %{http_code} --max-time 3 $url || true) if [ $code 200 ]; then echo OK: $url else echo FAIL: $url - $code return 1 fi }关键是-o /dev/null丢弃响应体-s静默模式不打印进度-w %{http_code}只输出状态码--max-time 3限制总请求时间不超过 3 秒。最后的|| true是防止 curl 在超时或连接失败时返回非 0 导致脚本提前退出因为我们要的是状态码而不是 curl 自己约定的错误码。调用方式写在下面if check_http http://127.0.0.1/healthz; then echo primary ok else echo primary fail, switch to backup fi如果是不带 curl 的精简环境可以用/dev/tcp做端口探测但那是 bash 内建功能只能用于 bash不能用于 shif timeout 3 bash -c /dev/tcp/127.0.0.1/8080 2/dev/null; then echo port 8080 open else echo port 8080 closed fi这里timeout 3防止 TCP 连接长时间半开状态/dev/tcp/...是 bash 的特殊文件重定向不能写成sh script.sh执行。这类看起来很简单但到处是暗坑的脚本正是合集里最值得逐个过一遍的部分。读脚本比跑脚本更重要因为跑通了也不代表你理解了边界网络脚本尤其如此真正的生产环境不会像本地 loopback 这么客气。3. 跑通脚本前的准备执行方式、路径感知与冒烟测试3.1./script.sh与bash script.sh的差别拿到一个合集脚本先不要直接./xxx.sh因为./方式要求两个条件文件有可执行权限且第一行的 shebang 指向的解释器存在。bash script.sh只需要你能读这个文件解释器由你显式指定这也是排障时最稳妥的执行方式。两者混用最容易遇到的问题脚本写#!/bin/sh而系统/bin/sh指向dash如果你用sh script.sh得到一堆数组语法错误用bash script.sh反而正常。先看文件类型file clean_logs.sh # 输出: clean_logs.sh: Bourne-Again shell script, ASCII text executable然后看 shebanghead -1 clean_logs.sh # 常见: #!/bin/bash这个问题的本质是 shell脚本文件语法 的解析器差异bash 支持[[ ]]、source、function关键字dash只支持 POSIX 的[ ]、.、函数定义。合集里不少脚本为了兼容写成#!/bin/bash但个别作者图省事写成#!/bin/sh。我的建议统一用 bash 执行除非你明确知道它要跑在其他解释器上。执行命令时可以用bash -n script.sh做语法检查它只解析而不执行能提前暴露最粗的语法问题不用等运行到一半才报错。若你手边只有sh环境也不要慌先ls -l /bin/sh看它软链到谁如果指向 bash那多数脚本都能跑如果指向 dash你就得接受一部分 bashism 会失效的现实。3.2 相对路径脚本离开原始目录就找不到文件第二个常见问题是路径。合集脚本里经常出现./logs、conf/config.ini这类相对路径因为作者开发时就在那个目录里。你把脚本拷贝到 /opt/scripts 下或者用 cron 去调它工作目录一变所有相对路径全部失效。解决办法是让脚本自己切换到所在目录#!/bin/bash # 切换到脚本真正所在的目录防止 cron 下工作目录变化 BASE_DIR$(cd $(dirname ${BASH_SOURCE[0]}) pwd) cd $BASE_DIR || exit 1这里${BASH_SOURCE[0]}是脚本自身的路径dirname取出目录名cd ... pwd将路径规范化后再赋给 BASE_DIR。老手常写$(dirname $0)但$0在有些调用方式下只是相对路径比如bash ./scripts/run.sh时是./scripts/run.sh而BASH_SOURCE[0]更准确地指向脚本文件本身。除非脚本被source两者差异不大但养成用 BASH_SOURCE 的习惯能少踩坑。对于 cron 场景还需要在脚本开头显式声明 PATH因为 cron 的 PATH 通常只有/usr/bin:/bin你/usr/local/bin里的命令它找不到。至少加一行export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin这行代码要在脚本中尽早出现因为后面所有命令都依赖它。这也是 cron 里脚本手动能跑自动跑不了最常见的原因。如果你在脚本里会调用其他第三方命令比如jq、docker那就把它们的路径也加到 PATH 里或者直接用绝对路径。写绝对路径虽然丑但在生产环境的 cron 里反而最可靠。3.3 冒烟测试先用bash -n和-x观察行为对合集脚本做任何改动之前先来一轮冒烟测试。三步语法检查、试运行看输出、按需要 dry-run。第一步bash -n clean_logs.sh echo 语法OKbash -n只做语法解析不执行任何命令所以对于所有if、case、for的格式错误能立刻发现。第二步如果脚本支持--help或直接跑会产生副作用先加bash -x看它到底要干什么bash -x clean_logs.sh --help 21 | head -50-x会打印每条命令展开后的实际内容21把 stderr 也接管head -50截断输出。看到它执行的rm -rf命令时你会庆幸自己没直接跑。第三步找脚本里有没有DRY_RUN、TEST、--pretend之类的开关grep -nE DRY_RUN|dry_run|pretend|test_mode clean_logs.sh很多合集里的脚本为了演示安全会预留这类变量但入口参数不一定写在 usage 里grep 一遍准能发现。如果没有这种开关我会临时把危险命令注释掉把rm替换成echo rm跑通后再改回来。这不是丢人而是对生产环境最基本的尊重。合集脚本是别人的经验不是你的授权书。冒烟测试最好在临时目录里做不要直接在原来脚本所在目录乱试因为你不知道它会不会清理自己。4. 改造脚本的三个关键语法从能跑到能改4.1 参数检查、默认值与 for 循环合集脚本中有相当一部分没有做参数健壮性处理直接$1、$2裸取一旦缺参数就报错或者产生破坏行为。建议拿到手先给脚本补上参数检查。以备份脚本为例#!/bin/bash # 用法说明 if [ $# -lt 1 ]; then echo 用法: $0 目标目录 [保留天数] exit 1 fi TARGET_DIR$1 KEEP_DAYS${2:-7} # 第二个参数没给时默认7 echo 备份目录: $TARGET_DIR, 保留 $KEEP_DAYS 天$#是参数个数$0是脚本名$1是第一个参数。${2:-7}是参数展开的默认值语法如果$2未定义或为空就用 7。这种写法比if [ -z $2 ]; then KEEP_DAYS7; else KEEP_DAYS$2; fi简洁得多也是 shell脚本基础知识 里最实用的部分。注意${2:-7}与${2:7}的区别前者不修改变量后者会把 7 赋给$2但对位置参数无效所以常用在环境变量上。for 循环在合集脚本里最常见的是批量处理文件配合 glob 展开。新手常犯的错误是不考虑没匹配到文件的情况for script in /opt/scripts/*.sh; do [ -f $script ] || continue bash -n $script echo 语法OK: $script done[ -f $script ] || continue这段很关键当 /opt/scripts 下没有 .sh 文件时*.sh不会被展开script的值就是字面量*.sh此时-f判断为假continue 跳过去避免对这个不存在的文件执行后续操作。如果你想遍历子目录改用find输出find /opt/scripts -maxdepth 2 -name *.sh -print0 | while IFS read -r -d script; do echo $script done-print0和-d 组合能正确处理文件名里有空格的情况这是一线操作里经常被忽略的细节。新版合集里很多脚本会用for f in $(find ...)这种老写法遇到空格文件名就会碎掉你把它改造成上面这种while read风格脚本的健壮性会明显上一个台阶。4.2 给脚本加日志和锁防止并发与静默失败合集脚本很多没有日志输出跑完像个黑匣子。至少加一个带时间戳的 log 函数并把关键步骤写进去LOG_FILE${LOG_FILE:-/tmp/ops.log} log() { echo $(date %F %T) $* $LOG_FILE } log 开始清理 $TARGET_DIR find $TARGET_DIR -type f -name *.log -mtime 7 -delete log 清理完成退出码 $?注意$?要立刻取因为一旦执行下一条 echo 或 date它就被覆盖了。第二条 log 里的$?实际是 echo 自己的退出码这是新手最容易忽略的。更严谨的写法是find $TARGET_DIR -type f -name *.log -mtime 7 -delete ret$? log 清理完成退出码 $ret锁文件也很必要。如果脚本被 cron 每 5 分钟调一次而一次执行要 10 分钟没有锁就会重叠执行导致日志文件被同时写坏、资源被耗竭。最常见的做法是flock它是 util-linux 自带的工具几乎所有发行版都有exec 9/var/lock/clean_logs.lock if ! flock -n 9; then echo 已有实例在运行退出 exit 1 fiexec 9文件把文件描述符 9 指向锁文件并创建它flock -n 9加非阻塞锁。-n表示拿不到锁立即失败而不是无限等待。脚本结束后文件描述符随进程关闭锁自动释放。用固定路径/var/lock/时要注意权限普通用户可能创建不了可以放到/tmp/下但/tmp可能被清理所以更稳妥的是放在脚本自己的目录里。如果你希望等待而不是放弃可以去掉-n让 flock 阻塞但加更长的超时时间会更好。锁文件逻辑是这个合集里最值得统一补充的部分因为很多脚本完全没考虑过并发。4.3 整理成工具箱软链、改名与 PATH 集成279 个脚本如果全部平铺在一个目录里使用体验很差——文件名要么check_mem_v2.sh要么final_new_backup.sh时间一长自己都找不到。我的做法是建立一个统一的工具目录如/opt/tools/bin把经过筛选和改造的脚本软链进去并去掉.sh后缀。软链的好处是脚本本体仍留在原目录升级时只需替换原文件软链不用动。mkdir -p /opt/tools/bin for f in /path/to/tools/check_*.sh; do base$(basename $f .sh) ln -sf $f /opt/tools/bin/$base done把/opt/tools/bin加入 PATHecho export PATH/opt/tools/bin:$PATH ~/.bashrc source ~/.bashrc之后再使用直接check_mem -w 80即可不需要关心脚本在哪个目录。这里有个小坑ln -sf的参数顺序是源在前、目标在后与 cp 的习惯一致但经常有人写反导致生成一个损坏的软链。用完后ls -l验证一下ls -l /opt/tools/bin/check_mem # 输出中应该有 - /path/to/tools/check_mem.sh 的指向这种先收集、后软链的方式让几百个脚本变成真正可支配的工具箱而不是浪费在找命令上的数码垃圾堆。这也是合集类资源最有价值的用法不追求全量运行只把其中 20% 变成日常依赖。如果软链后提示命令找不到多半是 PATH 没有生效检查一下~/.bashrc里的 export 是否写到了if [ -f ]条件外面别被默认模板坑了。5. 避坑指南shell脚本合集最常见的5个翻车现场5.1 Ubuntu 上正常CentOS/macOS 上报错逻辑对但命令不兼容现象脚本在 Ubuntu 测试通过拷贝到 CentOS 或 macOS 上执行就报sed: illegal option -- i或date: illegal option -- d。原因Linux 的 GNU 工具和 macOS 的 BSD 工具参数不一致sed -i在 GNU sed 下直接改文件BSD sed 要求sed -i date -d是 GNU 特有。解决写脚本时优先使用date -u %Y%m%d这种通用格式避免-d对需要兼容文件内容编辑的场景改用perl -pi -e或先sed ... file newfile mv newfile file。至少你得知道这层差异不要在开箱遇到报错时怀疑脚本逻辑。判断方法很简单先uname -s看系统类型再跑一句date -d 1 day ago %F如果报错就知道不能用 GNU 扩展。新版合集里如果作者目标环境是 Linux你在 macOS 上跑必须提前做隔离测试别直接上生产。5.2 cron 里跑不出结果手动执行一切正常现象你在终端执行脚本输出、日志都正常放进 crontab 后脚本没报错但结果文件是空的。原因cron 环境没有加载用户的环境变量PATH 里只有/usr/bin:/bin脚本里用到的/usr/local/bin不在其中另外 cron 的工作目录默认是用户家目录脚本里相对路径失效。解决在脚本开头显式设置 PATH 和切换目录然后用手动模拟 cron 环境的方式来验证env -i /bin/bash -c cd /home/user /opt/tools/bin/backup.shenv -i清空环境变量/bin/bash -c以干净环境执行这时候复现出来的错误和 cron 里基本一致。另外cron 脚本的输出要重定向到固定日志方便排查*/5 * * * * /opt/tools/bin/backup.sh /var/log/backup.log 21注意 crontab 里不要省略 ... 21否则报错只能靠系统邮件很多人根本不会去看。还有一个容易被忽略的坑cron 里用了%号在 crontab 文件里%是换行转义符必须写成\%所以脚本里如果有date %Y%m%d那就得转义。否则你看到的日志会奇怪地截断。5.3 目录名带空格脚本执行时突然爆炸现象备份目录是/data/My Backups脚本执行后不仅备份失败还错删了旁边的目录。原因变量未加双引号bash 在展开变量后会把带空格的值拆成多个词。rm -rf $BACKUP_DIR在BACKUP_DIR/data/My Backups时实际执行的是rm -rf /data/My Backups两个目录都被删除。解决所有变量展开都要加双引号rm -rf $BACKUP_DIR。处理文件列表时用 find 配合-print0和xargs -0。我也建议在危险脚本开头加上set -u和set -fset -u # 未定义变量直接报错不做空展开 set -f # 关闭通配符展开防止变量路径带 * 时被意外展开set -f适合这种场景但要注意它也会让*.log失效所以有时只在特定命令前使用。另外如果你需要在空格路径下执行命令可以强制用引号将整个路径包裹或者把目录名做成变量后再用cd $dir进入。这类问题在 shell脚本入门 阶段最容易遇到解决的核心原则只有一个凡是用到位置参数或变量的地方默认加双引号。5.4 脚本用了 bash 4 的语法但系统 bash 是 3.2现象脚本里有declare -A关联数组或${var,,}小写转换执行时报bash: declare: -A: invalid option或干脆语法错误。原因macOS 预装 bash 3.2部分精简容器用的是 bash 3.x这些版本不支持关联数组和许多 4.x 以来的新特性。解决先检测 bash 版本主动给出提示if [ ${BASH_VERSINFO[0]} -lt 4 ]; then echo 此脚本需要 bash 4 及以上版本 2 exit 1 fi或者在脚本开头的 shebang 写#!/usr/bin/env bash确保用 PATH 里第一个 bash 执行。如果要在老环境跑就得把关联数组改写成两个普通数组或 case 语句。比如原来用declare -A score([a]1 [b]2)改成两个平行数组keys(a b) values(1 2) for i in ${!keys[]}; do echo ${keys[$i]} - ${values[$i]} done这种改写逻辑清晰也更好维护。对合集里的脚本动手前先bash --version看看版本别等跑起来才傻眼。新版合集并不等于所有脚本都是 bash 4很多作者为了兼容只写 POSIX 语法但偶尔也会有高版本特性混进来。5.5 变量为空时危险命令没收住现象脚本里写rm -rf $BACKUP_DIR但BACKUP_DIR因为配置解析失败没有赋值变量变成空字符串命令实际变成rm -rf /。原因未定义变量默认展开为空rm -rf /会尝试删根目录虽然现在许多系统有保护但后果依然是毁灭性的。解决使用set -u让未定义变量直接报错同时在执行危险操作前做显式校验[ -n $BACKUP_DIR ] || { echo BACKUP_DIR 为空拒绝执行 2; exit 1; } [ $BACKUP_DIR ! / ] || { echo BACKUP_DIR 不能是 / 2; exit 1; } rm -rf $BACKUP_DIR[ -n $VAR ]判断非空加上第二条防呆确保即使配置被恶意或意外写成/也不会删根。这是每一个写 shell 脚本的人都该有的习惯凡是rm、mv、dd、mkfs前面必须做参数校验。如果你需要保护整个脚本而不是只保护某几行可以直接在脚本开头写set -u这样任何一个未定义变量都会中断执行。不过set -u也有副作用有时候你故意引用一个可能未定义的变量做默认值比如${VAR:-}这时set -u不会报错因为:-提供了回退但如果是$1和$2位置参数某些 bash 版本在set -u下对$1未赋值依旧会报错所以更安全的做法是对关键位置参数先做防御性赋值。6. 验证脚本真的开箱即用三个技巧与我的使用习惯6.1 用 shellcheck 做静态检查如果合集脚本没有经过完整测试我建议先跑一遍 shellcheck它能查出 90% 以上的引号问题、变量覆盖风险和可移植性坑。安装后执行shellcheck -x /opt/tools/bin/backup.sh-x允许跟随 source 外部文件适用于脚本用了source ./common.sh的情况。看到SC2086警告就知道哪一行变量没加引号SC2164提示 cd 后未判断结果。对于输出重点关注error级别warning 可以后续再看。把 shellcheck 纳入新脚本入库的门禁能减少大量线上事故。6.2 在临时容器里验证不弄脏真实环境对于要上生产环境的脚本我会先在 docker 容器里跑一遍确保它依赖的命令都存在。一条命令挂载当前目录docker run --rm -v $PWD:/scripts -w /scripts bash:5.2 bash -x check_sys.sh--rm容器退出后即删-v $PWD:/scripts把当前目录挂载为/scripts-w设置工作目录bash:5.2镜像自带较新的 bash。如果脚本需要真实系统信息可以用--pidhost、--networkhost让容器共享宿主 namespace但日常验证不需要。这种方式也适合测试脚本在sh与bash下的行为差异。6.3 把测试结果固化成一个简单的回归清单最后一个技巧是建立自己的脚本回归表把每次改造后的验证步骤记录下来。比如对于巡检脚本至少验证正常参数输出、缺参数报错、目录不存在时返回非 0。我一般用一个极简的测试目录结构tests/ check_mem/ normal.sh no_args.sh backup/ clean_dry_run.sh每个测试文件就是一个命令 期望退出码 期望输出。没有复杂的测试框架一个 for 循环加set -e就够了。时间久了你会发现真正让你放心的是我确认过边界在哪而不是脚本数量有多少。我的习惯是任何脚本进入我的工具箱前先补上set -u、加日志、套 shellcheck最后丢到容器里跑一次。这个流程帮我挡下了好几次险些把生产目录清空的翻车事故。279 个脚本听起来很多但真正值得留下的可能就 30 个耐心筛选比匆匆跑完意义大得多。希望帮到你。本文还有配套的精品资源点击获取
