服务器运维日常工作清单：高效服务器运维日常工作清单

做好服务器运维日常工作清单的核心就一句话：别指望靠人肉天天敲命令盯屏幕，把“每日自动巡检、每周安全审计、每月容灾演练”这三件事写成可执行脚本并挂上告警，就能干掉90%的半夜救火。

干了这么多年运维，见过太多团队每天忙得脚不沾地，其实全是在做无用功——要么服务器不报警坚决不看，要么拿个 Excel 表格天天手动填 CPU 使用率，纯属自欺欺人。真正靠谱的运维日常，就是每天早上花 5 分钟扫一眼机器人推送的异常汇总，没红灯就去写自动化工具或者优化架构，把精力留给真正值钱的事。

核心方案速览

一套能直接落地的服务器运维日常工作清单，必须按频率拆成三级节奏，避免每天事无巨细导致最后根本执行不下去：

• 每日必检（全自动脚本 + 早上5分钟核验）： 基础资源水位（CPU负载、内存、磁盘空间及 Inode）、核心服务存活状态（Nginx/MySQL/Redis/业务进程）、昨日备份文件完整性、严重报错日志（5xx、OOM、死锁）。
• 每周深巡（固定周五下午处理）： SSH 暴力破解与异常登录审计、数据库慢查询分析、无效大文件与僵尸进程清理、SSL 证书到期时间扫描。
• 每月大考（月底固定维护窗口）： 备份数据异地恢复演练、系统高危漏洞补丁评估、监控告警阈值复盘与垃圾规则清理。

实操细节深度拆解

光列条目没有意义，下面直接上生产环境能直接抄作业的脚本、命令和踩坑实录。

1. 每日基础资源与进程巡检（直接套用脚本）

很多新手巡检只看 df -h 和 free -m，结果服务器照样挂掉。真正的每日巡检必须同时盯死 Load Average（负载）、Inode 占用和核心端口存活。

下面这段 daily_check.sh 你可以直接丢到 /opt/scripts/ 下，配合 Crontab 每天早上 8:30 跑一次，有异常直接推给钉钉或飞书机器人：

#!/bin/bash
export PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

HOST_IP=$(hostname -I | awk '{print $1}')
LOG_MSG=""

# 1. 检查磁盘空间使用率 (使用 -P 防止挂载路径过长换行导致 awk 取错列)
DISK_WARN=$(df -Ph | awk 'NR>1 && int($5)>80 {print $6"("$5")"}')
[ -n "$DISK_WARN" ] && LOG_MSG="${LOG_MSG}\n[磁盘空间告警]: ${DISK_WARN}"

# 2. 检查 Inode 使用率 (小文件撑爆磁盘的元凶)
INODE_WARN=$(df -Pi | awk 'NR>1 && $5 ~ /%/ && int($5)>80 {print $6"("$5")"}')
[ -n "$INODE_WARN" ] && LOG_MSG="${LOG_MSG}\n[Inode告警]: ${INODE_WARN}"

# 3. 检查内存可用率 (看 available 而不是 free，Linux 会吃内存做 cache)
MEM_AVAIL=$(free -m | awk '/Mem:/ {printf "%.0f", $7/$2*100}')
[ "$MEM_AVAIL" -lt 15 ] && LOG_MSG="${LOG_MSG}\n[内存告警]: 剩余可用仅 ${MEM_AVAIL}%"

# 4. 检查 CPU 5分钟负载是否超过核数
CORES=$(nproc)
LOAD_5=$(awk '{print $2}' /proc/loadavg)
OVER_LOAD=$(awk -v l="$LOAD_5" -v c="$CORES" 'BEGIN {print (l > c*1.2) ? 1 : 0}')
[ "$OVER_LOAD" -eq 1 ] && LOG_MSG="${LOG_MSG}\n[负载告警]: 5分钟负载 ${LOAD_5}，核心数 ${CORES}"

# 5. 检查核心服务存活 (按自己业务增删)
for svc in nginx mysqld redis; do
    if ! systemctl is-active --quiet "$svc"; then
        LOG_MSG="${LOG_MSG}\n[服务异常]: ${svc} 未运行"
    fi
done

# 6. 检查系统是否触发过 OOM Killer (最近1天)
OOM_COUNT=$(dmesg -T 2>/dev/null | grep -i "Out of memory" | wc -l)
[ "$OOM_COUNT" -gt 0 ] && LOG_MSG="${LOG_MSG}\n[系统风险]: dmesg 发现 OOM 记录，请检查"

# 输出或推送告警
if [ -n "$LOG_MSG" ]; then
    echo -e "服务器 [${HOST_IP}] 巡检异常：${LOG_MSG}"
    # 这里替换成你的飞书/钉钉/企微 Webhook curl 请求即可
else
    echo "服务器 [${HOST_IP}] 今日巡检全部正常。"
fi

避坑指南：

• Crontab 环境变量坑： 脚本当中务必显式声明 export PATH=...，否则手动执行好好的命令，一进 Crontab 就报 command not found。
• 内存误判坑： 千万别用 free 列去算内存剩余！Linux 会把空闲内存拿去做 PageCache，看 free -m 里的 available 列才准确。

2. 备份核验与日志轮转（别等出事了才发现是空的）

我见过最惨的事故，是一个哥们儿写了 MySQL 定时备份脚本，跑了大半年都没报错。真到误删表要恢复那天，解压 .sql.gz 发现里面全是 0 字节——因为半年前数据库改了密码，脚本认证失败报错但没做状态码判断，照样生成了空压缩包。

每日备份核验必须做到两步：

1. 检查最新备份文件时间戳是不是 24 小时内生成的。
2. 检查文件大小是否符合预期（比如昨天是 500MB，今天突然变成 20KB，立刻告警）。

可以用这一行命令加进巡检脚本里做硬核校验：

# 检查 /data/backup/mysql 下最近24小时内是否有大于 10MB 的备份文件
VALID_BAK=$(find /data/backup/mysql -name "*.sql.gz" -mtime -1 -size +10M | wc -l)
if [ "$VALID_BAK" -eq 0 ]; then
    echo "[严重告警] 今日未检测到有效的 MySQL 备份文件！"
fi

日志清理别只会 rm -rf： 日常运维必须把所有应用日志接入 logrotate，防止单日志文件撑爆根分区。给一个 Nginx 日志切割的标准配置 /etc/logrotate.d/nginx：

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 nginx adm
    sharedscripts
    postrotate
        if [ -f /var/run/nginx.pid ]; then
            kill -USR1 `cat /var/run/nginx.pid`
        fi
    endscript
}

踩坑提示： 网上很多教程喜欢教人用 copytruncate 参数来省掉 postrotate 重载，千万慎用！高并发场景下，复制文件和清空原文件之间存在毫秒级时间差，这期间写入的日志会直接丢失；而且大文件拷贝极其吃磁盘 IO，瞬间能把业务拖卡。老老实实用 USR1 信号通知进程重新打开日志文件句柄才是正解。

3. 每周安全审计与 SSL 证书监控

每周五下午固定花 15 分钟做一次安全面扫描，主要查三件事：谁在爆破我、有没有异常定时任务、证书快没过期。

• 查异常登录与暴力破解（CentOS/RHEL 看 /var/log/secure，Ubuntu/Debian 看 /var/log/auth.log）：

# 统计近一周 SSH 登录失败次数最多的前10个 IP
grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -n 10

如果发现某个 IP 刷了几千上万次，直接检查 fail2ban 有没有生效，或者安全组里是不是把 22 端口全网 0.0.0.0/0 放开了——生产服务器 22 端口只允许跳板机或固定办公 IP 访问，这是底线。

• 查定时任务与异常出网连接（防挖矿木马潜伏）：

# 列出所有用户的定时任务
for u in $(cut -f1 -d: /etc/passwd); do crontab -u "$u" -l 2>/dev/null; done

# 查看当前所有非本地的 ESTABLISHED 外部连接，留意陌生境外 IP
ss -antp | grep ESTAB | awk '{print $5, $6}'

• SSL 证书过期扫描： 多少大厂都栽在证书过期这种低级失误上。直接用 openssl 批量扫一遍线上域名剩余天数，低于 15 天自动提醒续签：

DOMAIN="example.com"
END_DATE=$(echo | openssl s_client -servername $DOMAIN -connect $DOMAIN:443 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)
DAYS_LEFT=$(( ($(date -d "$END_DATE" +%s) - $(date +%s)) / 86400 ))
echo "域名 ${DOMAIN} 证书剩余天数：${DAYS_LEFT} 天"

4. 每月容灾恢复与配置版本化

没做过恢复演练的备份，等于没有备份。 每月月底挑个测试机或闲置虚拟机，把线上的数据库备份和代码包拉过去走一遍完整还原流程，记录耗时，顺便核对有没有漏掉 Redis 持久化文件、上传的图片附件或第三方密钥。

另外，强烈建议把 /etc/nginx、/etc/supervisor、防火墙规则、Crontab 等核心配置全部纳管到一个私有的 Git 仓库里。写个定时任务每天凌晨自动 git add . && git commit && git push。哪天手滑改崩了 Nginx 配置或者不知道谁改了参数，直接 git diff 一眼抓出凶手，一秒 git checkout 回滚，比翻聊天记录扯皮强一万倍。

高频关联问题拓展

执行服务器运维日常工作清单的过程中，有三个高频“灵异事件”最容易让新手抓瞎，顺便把排查套路给你备好：

问题1：磁盘明明还有 30% 空间，服务却报错 No space left on device

基本只有两个原因：

1. Inode 耗尽： 运行 df -i 发现某个分区 IUse% 到了 100%。常见于 PHP Session 没清理、邮件队列堆积、或者业务代码把百万级小缓存文件全丢进同一个目录。
   • 定位大户目录： for i in /*; do echo $i; find $i 2>/dev/null | wc -l; done（按层级往下缩小范围）。
   • 清理避坑： 几百万个小文件千万别直接 rm -rf *，Shell 会直接报 Argument list too long 甚至卡死磁盘。创建一个空目录 mkdir /tmp/empty，用 rsync --delete-before -a -H -v /tmp/empty/ /目标脏目录/ 秒清。
2. 文件被删但句柄未释放： 有人看磁盘满了，直接 rm -rf 删了一个正在疯狂写入的 50G 日志文件。文件在目录树里消失了，但只要进程没重启，文件句柄（FD）还占着磁盘块。
   • 排查命令： lsof | grep deleted（重点看 SIZE 列巨大的条目）。
   • 解决方法： 重启或 Reload 对应占用进程即可释放。切记以后清理正在写入的大日志，永远用 > /var/log/app.log 或 truncate -s 0 清空内容，别用 rm！

问题2：巡检发现 CPU 飙到 100%，疑似中了挖矿木马怎么止损？

很多人的第一反应是 top 找到 PID 然后直接 kill -9，结果刚杀完 5 秒钟又冒出来一个新 PID。正确的应急顺序是：

1. 先挂起别强杀： 用 kill -STOP <PID> 冻结木马进程让 CPU 先降下来，同时保住现场方便查它的启动路径和守护进程。
2. 斩断外联与持久化： 检查 /proc/<PID>/exe 找到本体路径；清理 crontab、systemd 异常服务 (/etc/systemd/system/)、~/.ssh/authorized_keys 里的陌生公钥。
3. 破除文件锁： 如果删不掉木马文件提示 Operation not permitted，八成被加了只读锁定，先 lsattr 文件名 看有没有 i 或 a 属性，用 chattr -ia 文件名 解锁后再删。
4. 终极建议： 只要确认机器被提权植入了 rootkit 或系统命令（如 ps、netstat）被替换，别指望自己能清理干净，备份业务数据，重装系统并修改所有密码和密钥才是唯一安全的选择。

问题3：服务器多了（几十上百台），这套清单怎么批量跑？

超过 5 台机器就别一台台 SSH 上去折腾了，把脚本和命令收口到中控机上：

• 轻量级批量执行： 上 Ansible，不需要在目标机装客户端，配好 SSH 免密后，一条命令就能把全网机器的磁盘和负载扫一遍：

  ansible all -m shell -a "df -Ph | awk 'int(\$5)>80'; uptime"

• 正规军监控体系： 机器上规模后，直接用 Prometheus + Node Exporter + Grafana + Alertmanager 替代人工巡检脚本。Node Exporter 负责每秒采指标，Alertmanager 负责把磁盘 >85%、内存不足、服务宕机直接打到群里，运维的工作就从“跑脚本找问题”彻底升级成“看告警处理问题”。

结尾总结

说到底，制定服务器运维日常工作清单不是为了应付领导检查、凑一份好看的运维周报，而是为了把人的记忆力从繁琐重复的琐事里解放出来。人总会犯懒、总会漏看一行日志，但定时运行的脚本和监控阈值不会骗人。

今天回去先不用搞大而全的监控平台，直接把上面的巡检脚本改改服务名丢进 Crontab 跑起来，再把数据库备份校验加进去。以后每踩一次线上故障的坑，就把对应的排查动作补进你的清单里——用半年时间打磨出一套贴合自己业务的自动化巡检体系，你的运维生涯基本就能告别“半夜惊醒”了。