云服务器日常运维自动化：定时任务与日志轮转的三件小事

云服务器刚买回来时，运维基本靠手动：想起来就上去看一眼磁盘，想起来就清一次日志。项目一忙就顾不上，等到磁盘写满、服务写不进日志、备份停了几个月才发现，往往已经是故障现场。运维自动化的起点不需要很复杂的平台，先把三件重复劳动交给机器：定时备份、日志轮转、磁盘与服务巡检。把这三件做扎实，一台小服务器就能长期稳定运行。

一、定时备份：先定策略，再写脚本

备份最容易犯的错误是只备份代码。代码本身在版本控制里随时能找回，真正丢了找不回来的是数据：数据库、用户上传的文件、应用的配置文件。备份清单要先把这三类列清楚，缺一类都不算完整备份。

备份策略不用贪多，抓住三个要素就够用：备份什么、多久一次、保留多久。对个人小项目来说，一个可行的起点是每天凌晨备份一次数据库和配置文件，每周备份一次完整数据目录，本地保留最近 7 天的备份，再把每周那份同步到对象存储或另一台机器上。异地那一份是关键：备份和服务器放在同一块盘上，磁盘坏了就等于没备份。

写备份脚本时有几个细节值得注意。第一，备份前先确认数据库备份命令真的跑通了，不要只看脚本没有报错就放心，定期拿备份文件在测试环境恢复一次，能恢复的备份才是备份。第二，备份文件名要带日期，方便按时间找回，也方便按保留期自动清理过期文件。第三，备份完成后记一条日志，写清备份了哪些内容、文件多大、是否成功，出了问题第一时间能从日志里看到，而不是等到要用时才发现备份是空的。

定时任务用系统自带的 cron 就够了。任务写好后先手动跑一次，确认输出和预期一致，再交给 cron 定时执行。还要注意 cron 环境的 PATH 和工作目录跟交互终端不一样，脚本里要用绝对路径，环境变量也要在脚本里显式设置，否则手动能跑、定时跑就失败，是最常见的坑。

二、日志轮转：别让日志把磁盘吃光

日志是排查问题的第一手资料，但放任不管的日志也是磁盘杀手。一个访问量不大的小项目，应用日志加访问日志，一年下来也能攒出几十 GB。日志轮转要解决的其实就两件事：单个文件别无限变大，旧文件别无限保留。

Linux 上现成的 logrotate 就是干这个的，系统服务和 Nginx 的日志大多已经配好了轮转，自己的应用日志需要单独加一份配置。配置里写清轮转周期、保留份数、是否压缩、轮转后是否需要通知应用重新打开日志文件。压缩后的旧日志体积通常只有原来的十分之一左右，保留两到四周既够排查问题，又不会占用太多空间。

这里有一个容易踩的坑：有些应用是打开日志文件后一直往同一个文件描述符里写，轮转只是把旧文件改了名，应用还在往改名后的旧文件里写，新文件一直是空的。解决办法是在轮转配置里加上让应用重新加载或重启的动作，或者让应用按日期生成日志文件名，从根上避免这个问题。配好轮转后要验证一次：手动触发轮转，看新日志是不是正常写入、旧日志是不是按预期压缩和清理，验证通过才算配好。

除了轮转，还要给日志定一条红线：日志里不写密码、令牌、完整的用户隐私信息。很多故障排查时需要把日志贴出来求助，日志里一旦混进了敏感信息，清理起来非常被动。写日志时只记必要的信息，敏感字段一律脱敏或省略，这条规则要在写代码时就养成习惯。

三、巡检脚本：每天替你看一眼服务器

备份和日志都自动化之后，还差一双每天替你看一眼服务器的眼睛。巡检脚本不需要监控平台那么全，覆盖四个指标就够了：磁盘使用率、内存使用率、关键服务进程是否在运行、备份任务昨天是否成功。脚本跑完后把结果写进一个巡检日志，异常时发一条提醒。

阈值的设置要结合实际：磁盘使用率超过 80% 就提醒，留出清理和扩容的时间；关键服务进程不在，就尝试重启一次并记录重启结果；备份任务失败，第二天早上就要能看到提醒。提醒渠道用自己每天一定会看的就可以，邮件、即时消息都行，关键是提醒要能到达人，而不是只写在服务器上的某个日志文件里等着人去翻。

巡检脚本本身也要定期检查。脚本依赖的命令、路径、提醒渠道变了，脚本就可能悄悄失效。每个月花几分钟手动跑一次巡检脚本，确认它报告的内容和服务器真实状态一致，这个习惯能避免“监控以为一切正常，实际上监控早就挂了”的尴尬。

四、从手动到自动的顺序

这三件事建议按这个顺序落地：先把备份做起来并验证一次恢复，再配日志轮转并验证写入，最后写巡检脚本并让它每天运行。每做完一件，就验证一件，不要三件一起上、最后不知道哪件没生效。验证的标准也很简单：备份能恢复、日志会轮转、巡检会报警。

自动化不是为了炫技，而是把“想起来才做”的事变成“每天一定做”的事。服务器最怕的不是配置不够高级，而是运维全靠记性。把备份、日志、巡检这三件小事交给机器，剩下的精力才能真正花在做产品上，而不是花在救火上。