为什么需要审计日志定时巡检？
审计日志这东西，说白了就是系统里的一本“流水账”。
谁在什么时候做了什么操作，登录、退出、改配置、删文件……全记在上面。我刚开始做运维的时候觉得它可有可无，直到有一次——凌晨三点，客户反馈数据被删了。我翻日志一查，发现那个删除操作发生在两天前，而我只是每周一才手动看一次日志。嗯，从那以后我彻底明白了：审计日志如果不盯、不查、不告警，那就等于白记。
手动检查？行不通
你想想看，一个中等规模的服务器群，一天能产生几万甚至几十万条审计日志。靠人一条条翻？不现实。我见过不少团队的做法是：每周让运维哥儿们ssh上去，grep一下关键字，然后截图汇报。结果呢？
- 容易遗漏：只看关键词，漏掉上下文关联的异常。
- 时效性差：发现问题时已经过去好几天，攻击者早跑了。
- 依赖个人经验：新人可能根本不知道哪些日志值得留意。
- 无法形成闭环：发现了问题，没有自动触发的响应机制。
我曾经踩过的坑：有一次安全审计，对方要求我们提供过去三个月的所有异常登录记录。我翻遍了手动备份的日志文件，发现中间因为磁盘写满丢了两天的数据。合规检查差点没通过。
定时巡检到底能解决什么？
说白了，就是把“人工盯”变成“机器自动盯”，而且盯得更勤、更全。
| 维度 | 手动检查 | 定时脚本巡检 |
|---|---|---|
| 频率 | 周/月，甚至不定期 | 可配置（每小时/每天/每次触发） |
| 覆盖范围 | 靠人眼扫，有限 | 全量日志，规则引擎扫描 |
| 告警响应 | 无或人工事后 | 自动触发邮件/短信/webhook |
| 可靠性 | 依赖个人状态 | 脚本稳定，7×24在线 |
| 合规汇报 | 临时拼凑 | 自动生成巡检报告 |
核心价值：定时巡检不是替代人，而是把人的精力从“翻垃圾堆”中解放出来，去处理真正需要决策的事情。
一个典型的定时巡检流程
下面这张图是我自己设计的简易流程，你在大部分生产环境里都可以套用。
你可能会问：Shell脚本能搞定吗？
当然可以。我个人的习惯是先把核心逻辑写成一行grep+awk，然后包在函数里，最后挂到 cron 上。简单说就是：
#!/bin/bash
# 每天凌晨2点检查昨天的登录失败记录
yesterday=$(date -d "yesterday" +%Y-%m-%d)
count=$(grep "$yesterday" /var/log/auth.log | grep "Failed password" | wc -l)
if [ "$count" -gt 10 ]; then
echo "[WARN] 昨日失败登录: $count 次" | mail -s "安全告警" admin@example.com
fi你看，十行代码就能完成一次基础的定时巡检。当然，生产环境里我们还要考虑日志轮转、错误处理、去重、性能影响等等。这些在后面的章节里我都会结合具体的踩坑经验跟你说清楚。
一个小建议：刚开始不要追求“全量检查”。先挑三个最重要的日志类型（比如登录、sudo提权、文件变更）做起来，跑熟了再慢慢加规则。
什么时候你才需要这门课？
如果你符合以下任意一条，那这课就是为你准备的：
- 你正在手工 ping 日志，或者靠同事提醒才去看一眼。
- 你的团队被安全审计要求提供“定期巡检记录”，而你还不知道怎么自动化。
- 你写过几个 grep 脚本，但总觉得用起来不顺手、容易出 bug。
- 你想学点 Shell 实战技巧，又不想看那种“Hello World”式的教程。
其实运维圈子里有个说法：审计日志不是用来存的，是用来看的；不是用来看的，是用来盯自动盯的。手动检查就像守着水龙头等漏水，而定时巡检等于装了个自动报警器。两者的区别，你品，你细品。