一、轮换脚本概述
大家好，我是老赵。做运维这些年，我经手过不少自动化脚本，但要说最基础也最容易被忽视的，就是轮换脚本。说白了，轮换脚本就是一套自动化的“换班”机制——当某个资源达到阈值或时间点，自动把它替换掉。
我记得刚入行那会儿，公司一台日志服务器磁盘写满了，结果线上服务全挂了。老板问我怎么回事，我说日志没清理。他当时那个眼神……嗯，从那以后，我就把轮换脚本当成了运维的第一道防线。
什么是轮换脚本
轮换脚本，本质上是一个定时或触发式的自动化程序。它的核心动作就三个：备份、清理、重建。你想想看，不管是日志文件、数据库备份，还是临时任务队列，只要它不断增长，最终都会撑爆磁盘。轮换脚本就是提前给这些资源画好“红线”，到了就自动处理。
核心定义：轮换脚本 = 自动化资源生命周期管理。它确保每个资源都在可控范围内，不会无限膨胀。
我个人习惯把轮换脚本分成两类：
- 基于大小的轮换：文件超过 100MB 就切分
- 基于时间的轮换：每天凌晨 3 点执行一次
当然，实际项目中往往是两者结合。比如日志文件，既限制单个文件大小，又限制保留天数。
轮换脚本的应用场景
轮换脚本的应用场景其实比你想的要多。我挑三个最常见的来说：
1. 日志轮换
这是最经典的应用。Nginx、Tomcat、系统日志……哪个不轮换都会出事。我在项目中遇到过一台跑了半年的应用服务器，access.log 文件 40GB 大，vim 都打不开。后来我写了个 logrotate 配置，每天切割、压缩、保留 7 天，磁盘使用率直接从 95% 降到 30%。
小技巧：日志轮换时别忘了给新日志文件发 SIGHUP 信号，否则进程还在往旧文件里写。我曾经因为这个被坑过，排查了半天才发现日志没切成功。
2. 备份轮换
备份这东西，不做不行，做太多也不行。全量备份每天跑，磁盘很快就满了。所以需要轮换策略：
- 每天增量备份，保留 7 天
- 每周全量备份，保留 4 周
- 每月全量备份，保留 12 个月
这种“阶梯式”轮换，既保证了数据可恢复性，又控制了存储成本。我见过不少新手把备份脚本写成“只增不删”，结果备份目录比生产数据还大。
3. 任务调度
这个可能有点反直觉——任务调度怎么也要轮换？其实很多定时任务队列，比如 Celery、Resque，都有任务积压的问题。如果某个 worker 挂了，任务会堆积。轮换脚本可以定期清理超时任务，或者把失败任务移到死信队列。
| 场景 | 轮换对象 | 轮换策略 | 常见工具 |
|---|---|---|---|
| 日志轮换 | .log 文件 | 大小/时间切割 + 压缩 + 保留 N 天 | logrotate, cronolog |
| 备份轮换 | 备份文件/快照 | 阶梯保留（日/周/月） | rsync, duplicity |
| 任务调度 | 任务队列 | 超时清理 + 失败重试 | Celery, systemd timers |
轮换脚本的核心原则
写了这么多年轮换脚本，我总结出三条铁律。你只要记住这三条，基本不会出大问题。
- 幂等性：同一个脚本跑两次，结果必须一样。不能因为重复执行就把数据删光了。我习惯在脚本开头先检查状态，如果已经轮换过就跳过。
- 可观测性：轮换脚本必须留下痕迹。日志、监控指标、告警通知，至少占一样。否则出了问题你都不知道是脚本没跑还是跑错了。
- 容错性：脚本执行过程中如果出错，不能影响正在运行的服务。比如日志轮换时，旧文件还没压缩完，新进程已经开始写日志了——这种情况要处理好。
警告：千万不要在生产环境直接测试轮换脚本。我曾经手滑在线上跑了个没调试好的备份轮换脚本，结果把当天的全量备份删了，还好有异地备份才没出事。先在测试环境跑三遍，确认无误再上线。
下面这张图是我自己总结的轮换脚本知识体系，你可以对照着理解：
嗯，以上就是轮换脚本的基础概念。说白了，它就是运维自动化里最朴实但也最实用的一环。后面的章节我会带你一步步写出真正能上线的轮换脚本，包括具体的代码实现和避坑指南。