让自动化「到点自己跑」
上一节把流程写成了脚本。但脚本还要人敲一下才跑，这不够「自动化」。真正的自动化是：到点自己跑、定期自己跑、出了事自己知道。 这一节讲定时触发。
目标：把「每周一早上要手动跑一遍」的活，变成「到点自动跑」。
从「手动跑」到「定时跑」
手动：每周一 9:00 你记得去敲 ./report.sh
定时：每周一 9:00 系统自动跑 ./report.sh
定时触发，把「依赖人记得」变成「依赖系统执行」——人不会忘，活不会漏。
对 deploy-bot，你可以把「定期巡检 / 定期同步」这类重复动作设定时，让它到点自己执行，而不是每次靠人记着去触发。
定时触发的几种方式
| 方式 | 场景 | 例子 |
|---|---|---|
| 系统定时任务 | 本机定时 | cron（Linux/macOS）、任务计划程序（Windows） |
| CI 定时 | 和仓库绑定 | GitHub Actions 的 schedule |
| 服务端调度 | 云上定时 | 云平台的定时任务 |
按你的环境选一种即可，原理一样：到点触发脚本。
对 deploy-bot 来说，如果它跑在服务器上，用系统 cron 最简单；如果想和部署逻辑耦合、统一在 CI 里管，用 GitHub Actions 的 schedule 更顺。选哪种看它部署在哪。
一个 cron 示例
Linux/macOS 用 cron 定时跑脚本：
# 每天早上 9:00 跑报表脚本
0 9 * * * /home/you/scripts/report.sh
# 每周一早上 9:00
0 9 * * 1 /home/you/scripts/report.sh
用 crontab -e 编辑，crontab -l 查看。
Windows 用「任务计划程序」创建定时任务，效果一样。
给 deploy-bot 的「夜间对齐」动作设定时，长这样：
# 每天凌晨 3:00 把 staging 对齐 main 并部署
0 3 * * * /opt/deploy-bot/actions/sync-staging.sh
# 每天早上 8:00 巡检部署状态并上报
0 8 * * * /opt/deploy-bot/actions/status-report.sh
这样 deploy-bot 的「同步」「巡检」就到你点了。
定时任务的三个注意点
1. 环境要一致
定时跑的环境可能和交互环境不同（没有你的环境变量）。脚本里把环境变量、路径定义清楚。
deploy-bot 定时跑的时候尤其要小心：服务器环境可能没有你本地配的变量。在脚本里显式 export 依赖的变量（如部署目标、凭据路径），别依赖「碰巧有」。
2. 失败要能发现
定时跑没人盯着，失败了怎么办？——要能感知（下一节讲日志告警）。
deploy-bot 的定时动作失败了，光写进日志没人看也没用，必须有告警——这是它敢无人值守的前提。
3. 先试后定
别直接排产。先手动跑通脚本，再设定时，避免定时跑了个坏脚本。
给 deploy-bot 设定时动作前，先在 staging 上手动跑通一遍，确认脚本可靠了再交给定时器。
让 AI 帮你排定时
可以让 Codex 帮你写 cron 表达式或配置：
帮我写个 cron：工作日每天 18:00 跑数据备份脚本 /backup/backup.sh
它给你表达式，你确认后配上。
给 deploy-bot 设定时动作，也可以让它起草：
帮 deploy-bot 写 cron：工作日每天 20:00 跑 /opt/deploy-bot/actions/sync-staging.sh，
并把输出追加到 /var/log/deploy-bot/sync.log
拿到表达式后，先在非高峰时段手动验证再排产。
常见坑：定时任务跑在「另一个环境」，跟你本地完全不一样
定时自动化最常见也最隐蔽的坑：你本地手动跑好好的脚本，一设定时就莫名其妙失败。
真实场景：你在自己电脑上写好了 deploy-bot 的同步脚本，本地跑通，配进 cron。结果第二天醒来发现昨晚没跑成功——因为服务器上既没有你本地安装的工具，也没有你依赖的环境变量，脚本第一步就挂了。
为什么：cron 跑在服务器的非交互 shell 里，不加载你的交互环境变量，PATH、工具版本、凭据都可能是空的。你本地「有」，不代表定时环境「有」。
怎么破：脚本第一件事把用到的变量、PATH 显式定义好；先在目标服务器上手动跑通再设定时；配好定时后主动触发一次、并看日志确认成功，而不是干等明天。
小结
- 自动化 = 让活「到点自己跑」，不依赖人记得
- 定时方式：系统 cron / CI 定时 / 云端调度
- 注意：环境一致、失败能发现、先手动试通再定时
- 让 Codex 帮你写定时配置，你审查
下一节，讲日志、监控与告警。