cron 基线比对中的误报控制

基线比对的成败不在于能否生成一份差异清单，而在于这份清单能否被信任。cron 巡检最常见的失败往往不是漏检，而是告警太多：软件包升级重写了 run-parts 目录下的脚本，证书续期刷新了自己的定时任务，日志轮转相关的配置被重新安装。这些都会让比对结果不断出现新增条目。值班人员连续跳过多余告警之后，真正的异常就混在噪声里，不再引起注意。

误报来自三个方向

范围变化最容易被忽略。只把某一处 cron 目录纳入基线，却漏掉系统总表、cron.d 片段、run-parts 目录和其他调度器，比对结果就会随发行版和安装包的差异大幅变动。反过来，如果把包管理必然会写入的目录也纳入“必须零差异”的范围，误报就会成为常态。

表述差异属于另一类。条目顺序调整、注释重写、空白与换行变化，语义完全等价，差异工具却照样报告。这类噪声不会造成直接危害，但会持续消耗对告警的信任。

第三种最隐蔽：基线自身失准。快照里混进了临时文件，归属用户和权限没有固定，或者快照只留在被巡检的同一台机器上，那么一次本机的合法变更就能污染下一轮比对结果。

让比对先收窄，再判断

可行的做法是分层。先比较文件清单与属性：归属用户、权限位、lsattr 输出的属性标志。这一层出差异，基本可以直接定性，比如某个 cron 文件上凭空出现不可变属性，而变更记录里没有这一笔。属性层干净，再比内容哈希；哈希变了，最后才去看条目级语义。

语义层比对之前先做归一化：去掉注释与空行，压缩空白，按字段排序。这样顺序和格式的调整不会再触发告警。

白名单必须当成配置项管理，而不是口头约定。每一条豁免都要写清归属人、原因和到期时间。没有到期时间的白名单，等于永久静默，本身就是新的风险来源。

误报率背后是流程

判定的可靠依据是三条同时成立：有明确归属人、有可追溯的变更来源、命令链落到可信路径。只满足一条或两条时，正确动作是保留原文件、在行首加注释并写明日期与操作人，观察一到两个周期，而不是直接删除。删除会丢掉溯源线索，也可能在没弄清依赖之前打断业务。

验证窗口按最低频任务的一个完整周期来定：小时级任务观察两小时以上，每日任务看满 24 小时，每周任务建议看满 7 天。窗口内不要叠加其他 cron 相关变更，否则一旦出问题就无法归因。

需要补一层的是脚本本体。cron 条目本身看起来正常，但它调用的脚本被替换过，这在比对里完全隐形。凡是被调用的脚本，其归属用户、权限和修改时间都要进基线。

一条告警如果说不清涉及哪个文件、谁会因此改不了、出问题时如何在几分钟内解回去，它就不该进入值班队列。先把范围缩小到单个对象，再谈处置，误报率自然会降下来。