简介面向Linux运维工程师、系统管理员及运维开发人员这份资料定位为一份拿来即用的自动化运维脚本合集围绕日常巡检、批量管理、备份恢复、应用发布、日志处理与安全应急等高频场景帮助减少重复劳动并提升故障响应速度。包体约12KB共20个文件包含19个shell脚本与1个nginx.conf配置文件sh脚本按用途覆盖MySQL单/多循环备份、批量创建用户、批量远程执行命令、网站异常检测、Dos攻击IP自动屏蔽等整机级与业务级操作conf文件则为Nginx访问日志按天切割与分析提供配置支撑。脚本示例还包括一键部署LNMP、自动发布Java项目、服务器初始化、资源利用率查看、MySQL主从同步监控、100台服务器磁盘监控及CPU/内存高占用进程定位符合真实生产环境常见运维需求。目前已有82人学习适合有一定Linux基础、希望参考成熟脚本快速搭建自身运维体系的读者。1. Linux运维常用脚本为什么我劝你把命令敲成脚本而不是现场受苦服务器报警群里跳出磁盘使用率 96% 的告警你 ssh 上去 df -h 一看发现是应用日志把根分区写满了。手动清完日志第二天同样的告警又来一遍——这就是典型的临时工运维。Linux 运维常用脚本解决的就是这类问题把那些你重复敲过至少三次的命令组合固化成可复跑、带判断、会告警的脚本文件让服务器自己发现问题并自愈而不是每次都靠人肉救火。这篇文章覆盖磁盘日志处理、系统异常定位、网络连通性诊断、定时执行与避坑适合刚接手服务器的新手也适合想把手头命令整理成体系的熟手。我写的内容都来自实际被坑过的教训照着抄能少走弯路。2. 磁盘与日志类脚本先把服务器最容易爆炸的地方管住2.1 磁盘空间告警脚本30 行 Bash 保住一台服务器磁盘满这件事几乎是 Linux 服务器所有诡异故障的源头MySQL 突然写不进去、Nginx 返回 500、定时任务静默失败最后追查下来都是/或者/var分区满了。我一般会先写一个磁盘空间检查脚本挂在 crontab 里每十分钟跑一次阈值一到就发告警出来而不是等监控平台先发现。#!/bin/bash # 磁盘使用率检查脚本超过阈值打印告警并写日志 # 用法: ./disk_check.sh [阈值] 默认阈值 85% THRESHOLD${1:-85} LOG_FILE/var/log/disk_check.log ALERT_FILE/tmp/disk_alert.flag # 用临时文件做告警去重 df -h | awk NR1 {print $5, $6} | while read pct mountpoint; do # 去掉百分号只留数字 used${pct%\%} # 跳过 tmpfs 和光盘等特殊文件系统避免误报 case $mountpoint in /dev|/proc|/sys|/run|/boot/efi) continue;; esac if [ $used -ge $THRESHOLD ]; then message[$(date %Y-%m-%d %H:%M:%S)] 警告: $mountpoint 使用率 ${used}% 已超过阈值 ${THRESHOLD}% echo $message $LOG_FILE # 如果告警文件不存在说明是新告警可以在这里接邮件或企业微信通知 if [ ! -f $ALERT_FILE ]; then echo $message | tee /dev/tty touch $ALERT_FILE # 创建标记文件防止同一轮故障反复告警 fi fi done # 磁盘恢复正常后清掉告警标记 if ! df -h | awk NR1 {gsub(%,,$5); if ($50 $THRESHOLD) exit 0} END {exit 1}; then rm -f $ALERT_FILE fi这段脚本的核心逻辑是先df -h拿到所有挂载点的使用率再用awk把第五列Use%和第六列挂载点提取出来逐行判断。这里有两个容易被忽略的细节一是必须用NR1跳过df输出的表头行二是需要过滤掉tmpfs、devtmpfs这类内存文件系统它们的“使用率”高是正常的被算进去会天天误报。case那段就是干这个的。阈值参数化是我后来才加的THRESHOLD${1:-85}的意思是执行脚本时如果不传参数就用默认值 85传了就用你给的数。这样同一份脚本既能用 80% 盯根分区也能用 90% 盯数据盘不用复制多份。告警去重那段用的是/tmp下的标记文件第一次触发告警后创建文件恢复后才删除避免服务器磁盘已经红了还在每分钟刷屏告警把告警通道堵死。如果你要接真实的通知把echo $message | tee /dev/tty这一行换成 curl 发到企业微信机器人或者邮件命令就行。成熟的告警平台通常有 webhook 接口你只需要把 message 塞到 JSON 里 POST 出去。2.2 日志切割与归档别让日志把磁盘撑爆磁盘告警脚本管的是“已经满了怎么办”但更体面的做法是不让它满。日志文件每秒钟都在写一个高流量的后端服务每天的日志能长到几个 GB而大多数服务本身不做日志切割。这时候就要靠logrotate它是 Linux 自带的日志轮转工具几乎所有发行版都预装了它配置文件分两处主配置在/etc/logrotate.conf各项服务的切割规则放在/etc/logrotate.d/下。# /etc/logrotate.d/nginx 配置示例 # 作用对 Nginx 日志按天做切割保留 14 天切割后压缩 /var/log/nginx/*.log { daily # 按天切割 rotate 14 # 保留 14 份历史日志 compress # 压缩旧日志为 .gz delaycompress # 延迟一天压缩配合服务平滑过渡 missingok # 日志不存在时不报错 notifempty # 空日志不切割 dateext # 用日期作为切割后文件后缀 sharedscripts postrotate # 让 nginx 重新打开日志文件否则它会一直往旧文件里写 if [ -f /var/run/nginx.pid ]; then kill -USR1 $(cat /var/run/nginx.pid) fi endscript }logrotate的底层原理并不复杂它定期读取日志文件所在目录发现日志超过设定的轮转周期daily/weekly/size后把当前日志文件改名成带日期或序号的历史文件再创建一个新的空日志文件让服务继续写。真正难处理的是“服务一直持有旧日志文件句柄”的问题——你改名了日志文件但 Nginx 或 Java 进程还握着旧文件的 fd后续日志照样写进旧文件磁盘还是满。所以postrotate里要给进程发信号让它重新打开文件Nginx 用的是USR1这个信号是官方约定的平滑重开日志信号。我遇到过的最隐蔽的坑是delaycompress这个参数。它本意是让昨天的日志先不压缩等今天切割时再压缩昨天的这样 Nginx 重开日志后还能往旧文件里补一点零碎日志不至于丢数据。但如果你把compress和delaycompress一起用logrotate的压缩动作会延后一天磁盘占用峰值会比预期高出一倍。我的习惯是日志量大就省略delaycompress宁可压缩线程多跑一会儿也别让磁盘多撑一天。除了logrotate我还习惯在脚本里保留一套手动归档方案用于那些日志格式特殊、不适合用logrotate的老服务#!/bin/bash # 手动归档脚本把 7 天前的 .log 文件打包压缩并清理源文件 # 用法: ./log_archive.sh /var/log/app LOG_DIR${1:-/var/log/app} KEEP_DAYS7 find $LOG_DIR -name *.log -mtime $KEEP_DAYS 2/dev/null | while read f; do # 用 gzip 压缩压缩完改名为 .gz比 tar 省一步 gzip $f echo $(date %F %T) 已归档 $f done # 清理更早的压缩包只保留 30 天 find $LOG_DIR -name *.gz -mtime 30 -delete这个脚本的关键在find的-mtime参数7表示修改时间距今超过 7 天的文件。-delete是清理动作测试时建议先把-delete去掉跑一遍用-print看看它准备删哪些文件确认无误再加删除——这是我用后悔药换来的习惯。3. 用脚本快速定位系统异常从一百个进程里捞出真正的问题3.1 CPU 与内存异常一键排查脚本服务器卡了第一件事不是重启而是搞清楚是什么进程在吃资源。top命令能看但top是交互式的没法直接放进脚本里做自动化采集。我一般用ps加排序把 CPU 和内存占用前 N 的进程一次性捞出来再配合uptime看负载。#!/bin/bash # 系统资源异常排查脚本输出负载、CPU/内存占用 TOP 进程 # 适合接到告警后快速定位是哪个进程在搞事 echo 系统负载 (1/5/15 分钟) uptime echo echo CPU 占用 TOP 10 进程 ps -eo pid,ppid,user,%cpu,%mem,comm --sort-%cpu | head -11 echo echo 内存占用 TOP 10 进程 ps -eo pid,user,%mem,rss,comm --sort-%mem | head -11 echo echo 内存总量与使用 free -hps -eo里的-e表示显示所有进程-o后面跟要输出的列--sort-%cpu表示按 CPU 使用率降序排序-%mem同理。head -11是因为第一行是表头要取 TOP 10 就得取 11 行。comm列只显示进程的可执行文件名比args列短得多不会被一长串命令行参数刷屏。这个脚本看起来简单但它是很多排查脚本的基础。实际使用中我会把它放到 crontab 里每 5 分钟执行一次并把输出追加到日志文件这样服务器卡的时候事后能翻日志看那一时刻到底是谁在吃资源——不然等你反应过来 ssh 上去进程可能已经自己缓过来了什么都看不到。有一点要提醒ps看到的%cpu是进程自启动以来的平均 CPU 使用率不是瞬时值。一个进程如果平时占用低、刚才突然飙到 100%用平均值看可能只有 20%容易被忽略。想看实时突刺得用top -b -n 1这种非交互模式配合管道截取或者用pidstat但后者需要 sysstat 包。初级排查我用top -bn1 | head -20足够抓瞬时 TOP 比ps更准。# 查看瞬时 CPU 占用 TOP-b 批处理模式-n 1 只执行一次 top -bn1 | head -20 # 单独查某进程的线程数排查多线程死循环 ps -L -p PID | wc -l第二行的ps -L是查看进程内的线程列表wc -l数出线程总数。Java 应用线程数突然从 200 涨到 2000基本可以断定有线程泄漏或连接没释放这时候就要果断 dump 线程栈看堆栈了。3.2 僵尸进程与不可中断进程负载不高但系统卡死的原因还有一种让新手抓狂的情况CPU 和内存看着都不高但系统响应很慢load average高得离谱。这时候要看进程状态——ps输出里的 STAT 列Z是僵尸进程D是不可中断的睡眠状态通常是在做磁盘 I/O 且无法被打断。#!/bin/bash # 检查僵尸进程和 D 状态进程数量超过阈值输出告警 # D 状态进程过多往往是磁盘或 NFS 卡住导致的 zombie_count$(ps -eo stat | grep -c ^Z) dstate_count$(ps -eo stat | grep -c ^D) echo $(date %F %T) 僵尸进程数: $zombie_count, D状态进程数: $dstate_count if [ $zombie_count -gt 20 ]; then echo 警告: 僵尸进程过多建议检查父进程是否异常退出 ps -eo pid,ppid,stat,user,comm | awk $3Z {print} fi if [ $dstate_count -gt 5 ]; then echo 警告: D状态进程数异常可能是磁盘或网络存储出问题 ps -eo pid,stat,comm | awk $2D {print} fi这里grep -c ^Z是统计以 Z 开头的行-c参数直接输出匹配行数。僵尸进程本身不吃 CPU 和内存但它占着 PID 号数量多到一定级别会拖慢进程创建速度甚至导致无法 fork 新进程。僵尸进程的父进程如果是 init 或 systemd会自动被收养并清理一直残留说明父进程是个不处理SIGCHLD信号的程序——常见于一些老旧的 Java 守护进程解决思路是修代码而不是 kill 僵尸。D 状态进程的处理要更谨慎。如果是磁盘 I/O 导致的kill -9都杀不掉只能等 I/O 恢复。最常见的诱因是 NFS 挂载点失联——NFS 服务器挂了客户端所有访问该挂载点的进程全部卡进 D 状态umount -l卸载掉挂载点才能缓解。我遇到过整个网站“看起来活着”但所有后端 API 请求超时最后排查下来是备份服务器 NFS 断连导致的连锁效应。4. 网络连通性诊断脚本从端口探测到连接数统计4.1 批量端口连通性检查脚本别再用 telnet 一个个试了运维接到“某某服务访问不了”的情况先要判断是网络不通、端口没监听还是防火墙拦截。单个端口用telnet ip port或者nc -vz ip port很快但面对一批服务器、几十个端口手工试效率太低。我写过一个批量探测脚本把所有需要检查的“IP 端口”对写进一个文件里脚本逐个探测并汇总输出。#!/bin/bash # 批量端口探测脚本 # 用法: ./port_check.sh [目标列表文件] # 目标列表文件每行一个目标格式: 192.168.1.10 3306 LIST_FILE${1:-ports.txt} TIMEOUT3 # 超时时间,单位秒 if [ ! -f $LIST_FILE ]; then echo 错误: 找不到文件 $LIST_FILE exit 1 fi # 逐行读取目标列表 while read -r ip port; do # 跳过空行和 # 注释行 [ -z $ip ] continue [[ $ip ~ ^#.* ]] continue # 用 /dev/tcp 做 TCP 连接测试, 避免依赖 nc 命令 # bash 的 /dev/tcp/host/port 其实是把 TCP 连接抽象成了文件 timeout $TIMEOUT bash -c echo /dev/tcp/$ip/$port 2/dev/null if [ $? -eq 0 ]; then echo [OK] $ip:$port 可以连通 else echo [FAIL] $ip:$port 连接失败 (超时或拒绝) fi done $LIST_FILE这段脚本里最值得说的是bash -c echo /dev/tcp/$ip/$port这一行。很多人以为/dev/tcp是磁盘上的一个目录其实它是 Bash 内置的虚拟网络设备向它写入数据就等于向目标端口发起 TCP 连接。用它的好处是不需要安装 nc 或 telnet几乎任何带 Bash 的 Linux 环境都能跑。2/dev/null把错误输出吞掉因为连接失败时 bash 会打一堆“Connection refused”之类的报错我们只想看最终结果这个过程会输出到/dev/null。如果你想要更详细的错误可以去掉这个重定向把 stderr 打印出来看是超时还是拒绝。另一个关键点是timeout命令。TCP 连接在遇到防火墙 DROP 策略时默认要等系统 TCP 超时通常是 2 分钟才会返回失败不控制的话脚本会在一个连不通的端口上卡住。timeout 3的意思是 3 秒后强制结束这个连接尝试并返回非零退出码整个循环就不会被单个坏目标拖死。如果是跨网段的服务器探测nc命令有时比/dev/tcp更友好因为它能额外显示连接耗时。脚本里有 nc 就用nc -vz -w 3 $ip $port-w 3同样是超时控制-z表示不发送数据只探测端口。4.2 TCP 连接状态统计脚本发现半开连接和连接数暴涨端口是通的但服务就是慢这种时候要看连接状态。TCP 连接有十几种状态对运维来说最需要关注的是TIME_WAIT和SYN_RECV——前者过多通常说明短连接太频繁后者过多八成是遭受了 SYN 攻击或者是后端服务处理不过来。我用ss统计各状态数量比 netstat 快且更准确ss 是 iproute2 包自带的工具市面上主流发行版都有。#!/bin/bash # TCP 连接状态分布统计脚本 # 用于快速判断连接数异常以及是否存在半连接堆积 echo TCP 连接总数 ss -s | grep -i tcp echo echo 各状态明细 ss -ant | awk NR1 {print $1} | sort | uniq -c | sort -rn echo echo 到某端口(80)的连接数 TOP 客户端 IP ss -ant | grep :80 | awk {print $5} | cut -d: -f1 | sort | uniq -c | sort -rn | head -10ss -ant的含义是显示所有 TCP 套接字-a、不解析域名-n、只看 TCP-t。输出结果里第一列就是状态awk NR1 {print $1}跳过表头后提取状态列sort | uniq -c | sort -rn是个经典管道组合先排序让相同的状态相邻再统计去重并计数最后按数量倒序排。第三段命令的grep :80 筛选出本地端口是 80 的连接awk {print $5}取第五列即远端地址cut -d: -f1去掉端口只留 IP这样就能看到是哪些客户端的连接数异常暴涨。排查经验是正常情况下ESTABLISHED数量占绝大多数TIME_WAIT会有一些但不会持续飙升SYN_RECV应该接近零。如果SYN_RECV涨到几百上千且ESTABLISHED在减少基本可以断定有异常流量在打这个端口。处理手段一般是先确认业务是否正常再加防火墙规则限制来源 IP 的连接速率。这条排查路径不需要装额外的包一条一条拆开执行也能看懂结果适合作为远程诊断脚本的第一站。5. Linux 运维脚本的常见坑每一条都是交过学费的5.1 脚本在 Windows 上编辑过Linux 执行报错“No such file or directory”现象脚本文件明明存在权限也给了chmod x但执行./script.sh直接报No such file or directory文件权限和路径都没问题诡异得很。有些人在 Windows 下用记事本或 IDE 写脚本上传到服务器后就遇到这个问题。原因Windows 换行符是\r\nLinux 只认\n。Bash 解释器在解析第一行#!/bin/bash时把行尾的\r也当成了解释器路径的一部分等于在找bash\r这个不存在的程序所以报的错是“文件找不到”而不是语法错误。解决用sed -i s/\r$// script.sh一键清除行尾的\r或者用dos2unix script.sh。治本的办法是让编辑器默认使用 LF 换行。我现在每次从 Windows 上传脚本后第一件事就是跑一遍file script.sh看输出里有没有 “CRLF” 字样有就先转换再执行这个习惯省了我很多莫名其妙的排错时间。5.2 crontab 里脚本不执行手动跑却一切正常现象脚本在终端手动执行完全正常但放进 crontab 后就是不执行或者执行了但效果不对比如备份文件没有生成、告警邮件没发出来。原因crontab 的执行环境极其精简它不像登录终端那样加载/etc/profile和~/.bashrc所以PATH环境变量只有默认的几个目录。如果你的脚本里用了/usr/local/bin下的命令比如ansible、docker-composecrontab 环境里找不到这些命令脚本就会静默失败或在某个命令处报command not found而中断。解决在脚本开头显式加上export PATH/usr/local/bin:/usr/bin:/bin:$PATH或者干脆在脚本里使用命令的绝对路径如/usr/local/bin/ansible。判断是不是这个问题的办法是看 crontab 的日志绝大部分发行版会把 cron 执行记录写到/var/log/cron或者你在脚本开头加一句exec /tmp/script_debug.log 21把输出重定向到文件手动和定时各跑一次对比日志就能看到差异。5.3 脚本里用到管道符变量却在 while 循环里丢了值现象脚本里写result0然后echo a b c | while read x y z; do result1; done循环结束后echo $result输出的还是 0明明循环里已经赋值了。原因这是 Bash 的“每个管道子命令都是独立的子 shell”机制。while循环通过管道接收输入时是在一个子进程中执行的它里面对变量的修改不会影响到父进程的变量。这是 Bash 新手最容易翻车的语法细节。解决不要用管道把内容喂给 while 循环改用进程替换while read ...; do ...; done (echo a b c)这样 while 在主 shell 中执行赋值就能保留。或者干脆用for循环读取变量。如果不小心已经用管道写了吃一堑长一智改成进程替换就行这也是为什么我写的脚本里很少出现cat file | while read这种写法统一改成 file加 while。5.4 磁盘告警脚本每小时一封告警半夜把值班手机打爆现象磁盘使用率确实超过了阈值但告警脚本每 5 分钟跑一次每次跑都发一条告警值班人员凌晨三点收到三十多条相同内容的短信。原因脚本只判断了“当前是否超阈值”没有判断“之前是否已经告警过”。磁盘空间不是瞬间能清出来的一旦超阈值就会持续超阈值无脑重发告警等于把通知渠道刷废真正紧急的其他告警反而被淹没。解决用状态标记文件做去重。触发告警时创建一个标记文件后续执行检测到标记文件存在就只写日志、不再发通知磁盘空间恢复到阈值以下后删除标记文件。我前面磁盘告警脚本里ALERT_FILE/tmp/disk_alert.flag就是干这个的。注意标记文件不要放在被监控的磁盘上否则磁盘满到连标记文件都建不了会失效放/tmp或者内存盘里更可靠。5.5 脚本里忘加set -e命令失败后还继续往下执行现象部署脚本执行到一半已经报错了但它没有退出继续往后面跑最后把配置文件和备份覆盖得乱七八糟整个环境处于一个“既不是新的也不是旧的”的混沌状态。原因Bash 默认是“命令执行失败后继续执行下一条命令”除非你用连接或者主动判断$?否则它对错误是免疫的。这在交互式命令行里很友好但在自动化脚本里就是灾难。解决在脚本开头加set -euo pipefail。-e是遇到错误就退出-u是使用未定义变量时报错防止变量名拼写错误导致逻辑往下走o pipefail是让管道命令中任意一个环节失败都视为整条命令失败。这一行是脚本的护身符代价是要花一些时间改掉那些“假装成功”的写法比如某些命令返回 1 但是逻辑上可以接受的要用|| true包一下但收益远大于成本。6. 把常用脚本沉淀成你的运维工具箱组织方式与最后几个习惯跑通单个脚本只是第一步真正有价值的是把这些脚本组织成一套结构清晰的工具箱。我自己的目录结构是/opt/scripts/下面按功能分子目录disk/、network/、system/、deploy/、backup/每个脚本统一在文件名前加数字前缀表示执行顺序比如01_disk_check.sh、02_log_clean.sh。所有脚本的第一段注释都写清楚用途、参数说明、依赖命令、以及最后修改日期。这个习惯最初是我的导师带项目时定的规矩后来我自己带人也是用同样套路因为一个没有注释的脚本三个月后回来看真的跟黑匣子一样完全不记得当初的意图。版本管理我建议用 git哪怕只是本地仓库。脚本改坏了可以直接回滚比手动备份强太多。我会在脚本里加一行VERSION变量每次改动版本号加 0.1主版本号变了说明行为有大的调整。部署脚本它是属于线下环境自己维护不需要拉额外的工具链。验证一个脚本该不该写我的检验标准很简单这个命令组合我是否已经手动执行过两次以上如果是就应该写成脚本。不是所有事情都值得脚本化——一次性操作、需要大量交互判断的操作硬套脚本只会浪费更多时间。但凡是每周至少跑一次的重复劳动或者全公司几百台机器都要执行的检查类操作脚本化后省下来的时间很快就能覆盖写脚本的成本。最后再分享一个我个人的习惯每次处理完一起故障我会把排查过程和用到的命令整理成一个新的脚本丢进工具箱里。这样做的好处是故障不会白踩——下次遇到相似问题跑一遍脚本就能复现当时的诊断步骤不用重新回忆翻聊天记录。希望帮到你。本文还有配套的精品资源点击获取