审计确认任务真实执行是什么场景
合规检查与工作交接时，常被要求证明某个定时任务确实按计划跑了。只看某一处日志不足以支撑结论，稳妥做法是凑齐四条证据：调度器的触发记录、脚本自身的执行日志（含返回码与耗时）、业务产物的时间戳与大小、以及失败告警通道是否有效。四条互相印证，才能排除「进程跑过但什么也没做」这种假成功。
基本信息
| 适用平台 | GNU/Linux（调度服务、日志服务与业务日志） |
|---|---|
| 场景 | 审计与交接时证明任务执行 |
| 证据链 | 触发记录、脚本日志、业务产物、告警通道 |
| 核对周期 | 每日或每周例行核对 |
| 关键字段 | 返回码、耗时、产物时间戳与大小 |
| 注意 | 需确认日志是否持久化保存 |
典型使用场景
- 审计要求提供任务按时执行的证据。
- 交接时向接手人证明任务运行正常。
- 排查「任务显示成功但数据没更新」的假成功。
- 定期核对关键备份与清理任务的产物。
- 验证失败告警通道是否真的能触达。
证据采集
证据采集
journalctl -u cron --since today --no-pager | grep -c CMD # 触发记录条数
tail -n 3 /var/log/app/backup.log # 脚本自身日志
ls -l --time-style=long-iso /backup/mysql/ | tail -n 3 # 产物时间戳与大小
systemctl list-units --failed --no-pager | head # 失败单元巡检
for f in /var/log/app/*.log; do echo "== $f"; tail -n 2 "$f"; done # 批量看尾部
ls /var/log/journal >/dev/null 2>&1 && echo persistent || echo volatile # 日志持久化确认证据逐项读法
| 证据 | 作用 | 使用要点 |
|---|---|---|
| 触发记录 | 证明调度器执行过 | 来自调度服务的日志 |
| 脚本日志 | 证明脚本正常结束 | 关注返回码与耗时字段 |
| 业务产物 | 证明业务结果落地 | 时间戳与大小双重指标 |
| 告警通道 | 证明异常可被发现 | 定期自测，避免告警静默失效 |
| 日志持久化 | 证明历史可追溯 | 需确认日志目录存在且配置为持久化 |
| 核对周期 | 例行检查频率 | 与任务重要性匹配 |
要防假绿：脚本返回码为 0 但产物为空，或者产物存在但大小明显异常，都要纳入核对规则，不能只看成功状态。
日志未持久化时重启会丢失历史，审计场景要先确认日志存储配置是持久化模式，否则证据链断裂。
只核对进程跑过不够：必须用产物的时间戳与大小双重验证，才能证明业务结果真的产生。