把重复的构建、检查、同步交给定时任务，前提是脚本本身可重复执行、失败能被发现。这份文档按“写脚本 → 配定时 → 查日志”三步说明配置方法与验收标准。

一、适用范围

• 适用：每日构建与发布、定时探测站点可用性、定期同步内容、日志归档等可脚本化的重复操作；单机 Linux 环境下由 cron 触发的任务。
• 不适用：需要图形界面的手工发布流程；跨主机的任务编排与依赖调度，需引入专门的任务系统；应用内部的业务定时逻辑，应在应用代码中实现。

二、准备工作

项目	要求	检查方法
执行账号	使用专用账号，不使用 root 跑业务脚本	id、whoami
运行环境	脚本需要的解释器与依赖已安装在执行账号下	node -v、bash --version
目录	脚本与日志分目录，日志目录可写	ls -ld /srv/axis/bin /srv/axis/logs
时间口径	服务器时区与业务时区一致	timedatectl 或 date
权限	执行账号可读写目标目录，不可写入系统目录	试运行一次并检查退出码

• 脚本必须支持重复执行：重复跑不产生重复数据、不重复发布。
• 每次执行都要留下可判断成功与否的退出码与日志，不能静默失败。

三、操作步骤

本节拆成三个子步骤，建议按顺序执行；每一步完成后先确认结果，再进入下一步。

3.1 脚本编写

确定入参、工作目录、日志输出与退出码约定，写出可手工执行、可重复执行的脚本，并先在终端跑通。脚本只做一件事：发布归发布，检查归检查，混在一起后失败时无法判断停在哪一步，也无法单独重跑。详见 3.1 脚本编写。

3.2 定时触发

把验证过的脚本交给 cron 或系统定时器，明确执行账号、环境变量与并发约束，避免与手工执行冲突。时间表达式按服务器时区计算，触发时刻要用 date 实测确认，不能按自己的时区推算。详见 3.2 定时触发。

3.3 执行日志查看

按时间与退出码检索日志，确认任务按时执行、结果符合预期，并把失败信号接入告警。日志至少包含开始时间、结束时间与结果三要素；只有开始没有结束，说明任务被中断，需要结合系统日志一起判断。详见 3.3 执行日志查看。

三步走完后，人为制造一次失败再跑一遍：确认日志有错误行、退出码非 0、告警能触达。没有做过失败演练的定时任务，通常要等到真正出事时才发现它一直在静默失败。

四、验证方法

1. 手工执行 bash /srv/axis/bin/check.sh; echo $?，预期退出码为 0，输出包含开始与结束时间；退出码非 0 时先修脚本，不要急着加定时。
2. 用 crontab -l 确认条目已写入，时间表达式与预期一致，路径为绝对路径；相对路径在定时环境中会指向错误目录。
3. 等到触发时间后执行 tail -n 50 /srv/axis/logs/check.log，预期能看到本轮执行的开始、结束与结果行，且时间戳与计划时刻相差不超过一分钟。
4. 人为制造一次失败（如把目标目录临时改名），确认日志中出现错误信息且退出码非 0，验证失败可被发现；没有失败演练的任务不能算配置完成。

五、常见问题

现象	可能原因	处理方式
到点没有执行	cron 服务未运行或表达式写错	systemctl status cron，用 date 核对时区与表达式
手工能跑、定时失败	环境变量或 PATH 与登录环境不同	在脚本内写绝对路径，显式导出所需变量
日志为空	输出被重定向到别处或目录不可写	检查重定向路径与目录权限
任务重复执行	上次未结束又被触发	加锁文件，检测到锁则直接退出
出现中文乱码	系统 locale 未设置	脚本内设置 LANG，或日志统一用英文

六、回滚与注意事项

• 回滚：先注释或删除 crontab 条目停止触发，再恢复上一版脚本；不要直接删除日志，保留失败现场。
• 注意：脚本中的路径全部写绝对路径，定时任务的执行目录与登录 shell 不同，相对路径会指向错误位置。
• 注意：涉及发布的脚本必须支持“失败即停”，禁止在部分步骤失败后继续执行后续步骤。

上一页3.3 优化项定位

下一页3.1 脚本编写