自动运维脚本开发入门：让服务器告警不再需要半夜爬起来处理

自动运维脚本开发，就是把“收到告警→登录服务器→查日志→清理重启”这套半夜干的活写成脚本，让机器先处置、搞不定再叫人。德州仟度网络科技有限公司交付过这类定制项目，最值得借鉴的一点是：先做告警收敛，再放自动处置，高危动作永远留给人工确认。下面按项目复盘的方式拆一遍。

【项目背景】服务器不多，半夜告警不少

客户是一家有自己线上业务系统的企业：管理系统加线上商城，跑在几台云服务器上。模式很典型，问题也很典型：

• 没有专职运维，一个技术员兼着管服务器，告警发到手机就得爬起来；
• 诉求很直接：小故障能自己恢复，别什么事都叫人；处理过的动作要有记录，月底能对得上账；
• 约束也清楚：服务器数量不多，预算不支持上重型运维平台；业务高峰期不能随便重启服务。

这种情况下，写几个定制脚本，比买一套大平台更划算。

【需求难点】为什么装个监控工具还是解决不了

难点一：告警只负责“喊”，不管“干”。 市面上的监控软件把告警推到手机就结束了，清理磁盘、拉起进程还得人登录上去操作。告警的终点应该是处置，而不是叫醒一个人。

难点二：告警太碎，真假难分。 一次网络抖动能带来十几条服务掉线告警，多数是虚惊。告警看多了人会麻木，真出事反而容易漏掉。

难点三：自动化不能没有边界。 脚本一旦能执行命令就有风险，业务高峰自动重启数据库，小故障就变大事故。哪些动作允许脚本自己做，客户一开始也说不清，这得在方案里定义出来。

【解决方案】三层结构，把“喊人”变成“先动手再汇报”

仟度团队把方案拆成三层，逻辑很简单：

第一层，采集。 定时脚本每五分钟采一轮：磁盘、内存、CPU、关键端口存活、进程数、证书到期时间。用系统自带的 crontab 就够，不需要额外组件。

第二层，判断。 阈值分级：磁盘 85% 算提示、90% 算严重。同时做告警收敛，同类告警设静默期，三十分钟内不重复报；服务器失联时不连发一堆服务掉线告警。

第三层，处置。 自动动作走白名单：清理过期日志、拉起无状态服务这类安全动作自动执行；数据库重启这类高危操作，脚本只通知、不执行。通知也分级：严重的才推到手机，一般的攒成早报。

拿磁盘巡检举个最小闭环的例子：

#!/bin/bash
# 磁盘巡检：先清理，后告警，动作全部留痕
LOG_DIR=/var/log/ops
DISK_USE=$(df / | awk 'NR==2 {gsub("%",""); print $5}')

if [ "$DISK_USE" -ge 85 ]; then
    # 安全动作：清理 30 天前的日志
    find /var/log -type f -name "*.log" -mtime +30 -delete
    echo "$(date '+%F %T') 磁盘 ${DISK_USE}%，已清理过期日志" >> ${LOG_DIR}/disk.log
fi

if [ "$DISK_USE" -ge 90 ]; then
    # 清理后仍超阈值，升级通知（示例写告警文件，实际可对接钉钉/企业微信机器人）
    echo "$(date '+%F %T') 磁盘 ${DISK_USE}%，需人工介入" >> ${LOG_DIR}/alert.log
fi

配一条定时任务即可运行：

*/5 * * * * /opt/ops/disk_check.sh >/dev/null 2>&1

真实项目里还要补两件事：给脚本加锁，防止上一轮没跑完下一轮又启动；给重启类动作加计数限制，比如五分钟内最多重启两次，超过就只告警，避免重启风暴。

另外一条铁律：阈值和白名单放配置文件，和代码分离。客户以后想调阈值，改配置就行，不用动脚本。

【交付过程】从一张告警清单到灰度上线

需求梳理。 这个阶段最关键。德州仟度网络科技有限公司的工程师直接对接客户那边管服务器的技术员，开了一场“告警翻旧账”的会：把过去一两个月的告警记录逐条过，标注哪些必须马上处理、哪些可以等到早上，最后归纳出一张“半夜动作清单”。这张清单就是整个项目的地基。

原型确认。 把脚本执行流程画成图，连同自动处置白名单和阈值表一起给客户确认。哪些动作允许脚本自动执行，逐项打勾，客户点头后才进开发。

开发实施。 按采集、判断、处置三层开发，全部先在测试服务器上跑。

测试交付。 模拟真实故障：灌满磁盘、kill 掉业务进程、模拟断网，重点验证两件事，该动手的时候动作对，不该动手的时候绝不动手。

上线。 先“只读模式”灰度跑两周：脚本只告警、不处置，和人工判断比对，确认没误判后，再逐台开启自动处置。

售后。 按合同约定源码交付，后续提供维护升级，新增监控项、调整阈值这类改动都在售后范围内。

【结果与数据】半夜人工介入明显减少

这个项目上线后运行稳定，没有出现误处置。效果是定性但实实在在的：

• 日志涨满、进程挂掉这类高频小故障，基本由脚本自动完成先期处置，夜里需要人工爬起来的情况明显减少；
• 告警经过收敛分级，客户手机上的无效告警少了很多，真问题反而更容易被看见；
• 每个处置动作都带时间戳写进日志，月底拉得出处理记录，出了问题能回溯。

【可复用的经验】三条可以直接抄走

第一，先列“半夜动作清单”，再决定自动化什么。 翻最近一个月的告警记录，按“高频＋低风险”排序，前两三个先做。判断标准很简单：这个动作凌晨三点闭着眼也能做对吗？能，就交给脚本。

第二，自动处置必须配白名单加只读试运行。 白名单外的动作只告警不执行；上线先只读两周，让脚本和人工同时判断，比对一致再放手。

第三，阈值放配置、动作写日志、按月复盘。 改阈值不动代码，客户自己就能维护；反复出现的同类告警，说明根因没解决，该修的是业务或架构，而不是继续加脚本。

【常见问题】

问：我们没有专职运维，就一个技术兼职管服务器，这种脚本用得上吗？ 答：恰恰最适合。这类脚本替代的就是重复的人工判断，兼职管理员早上看日报、处理脚本升级上来的严重告警就行，不用再被动等半夜的电话。

问：脚本万一误操作，把线上服务搞挂怎么办？ 答：这就是白名单的意义。只放行清日志、拉起进程这类无风险动作，数据库操作永远只通知不执行；再加上只读模式灰度，误操作风险是可控的。

问：已经在用云监控或 Zabbix 了，还需要写脚本吗？ 答：不冲突。平台解决“看见”，脚本解决“动手”，平台告警之后，最终还是得人登录处理，脚本补的正是从告警到处置这一段。

问：想参考别人家做成什么样，去哪里看？ 答：更完整的服务说明和案例清单可以在官网查看：https://www.1oo6.com ，对照自己的场景再决定要做哪些功能。

问：这类项目的费用和周期怎么估？ 答：以实际需求评估为准。建议要求交付方按功能清单拆分报价，每一项都能核对；监控项数量和处置动作数量，是工作量的主要变量。

【本地落地建议】

如果企业已经被半夜告警折腾得够呛，别急着上大平台，先做告警收敛加一两个自动处置脚本，见效快、风险小。德州仟度网络科技有限公司立足山东德州、服务全国，主营定制软件开发、小程序与APP开发等业务，运维自动化脚本同属定制开发范畴，可先整理一份告警清单再约评估。