我不是专业运维,但手上要管的机器和服务不少。这些年我最大的体会是:能自动化的就别手动做。这篇分享我常用的三个小脚本,以及我写它们时踩过的坑。

我写脚本的判断标准

图 1:我写小工具的流程

我的标准很粗暴:同一件事一周要做三次以上,就值得写个脚本。写脚本花二十分钟,但能省下几个月里反复的复制粘贴。

脚本一:定时备份 + 自动清理

它干什么:每天固定时间打包指定目录,保留最近 7 份,超出的自动删掉最旧的。

为什么这么设计:我以前是「想到才备份」,结果总是忘了。改成定时之后,我只需要偶尔看一眼备份列表。保留 7 份是个经验值 —— 太少了不够回滚,太多了占空间。

脚本二:服务健康检查

它干什么:每隔几分钟检查一次服务是否正常,不正常才发通知。

关键点:只在异常时通知。我一开始写的是「每次检查都发消息」,结果一天几十条通知,后来我干脆把它屏蔽了 —— 这等于没做监控。改成「只在异常和恢复时通知」之后,才有用。

脚本三:一键收集日志

它干什么:把服务日志、系统状态、配置摘要打包成一个文件,方便排查。

为什么需要它:排查问题时,我要来回登录机器、翻好几个目录。现在一条命令打包好,下载下来慢慢看。

我踩过的坑

1. 脚本失败没人知道。写了自动化最怕它悄悄挂掉。所以每个脚本我都加了日志,重要脚本还会在失败时通知我。
2. 路径写死在代码里。一开始我用绝对路径,换台机器就全废。后来我都改成从配置读。
3. 不做幂等。脚本跑两遍会重复执行操作,现在我会先判断「这件事是不是已经做过了」。
4. 不留执行记录。出问题的时候,我根本不知道它上次跑成功没有。现在每个脚本都会输出一行结果。

我的结论

写小工具这件事,最大的收获不是省了那点时间,而是我对自己系统的了解深了一大截。

为了写脚本,你必须先弄清楚「这个东西到底怎么运作的」,这个过程本身就很值。如果你手上也有重复劳动,我建议从一个二十行的小脚本开始,别一上来就搞复杂的框架。