一、审计日志基本概念
1.1 什么是审计日志
审计日志，说白了就是系统里的一份“行为记录单”。它记录了谁、什么时间、干了什么、结果如何这些关键信息。
我刚开始接触这个领域时，总觉得审计日志就是普通日志的“升级版”。后来才发现，两者压根不是一回事。普通日志更多是给开发人员排错用的，而审计日志面向的是合规审查、安全溯源这些场景。
举个例子，你在电商平台下单，后台记录的“用户ID 12345 在 2024-01-15 14:30:22 提交了订单 A10086” 就是一条审计日志。它记下了事件的全貌，而不是简单的调试信息。
审计日志核心四要素：
- 主体：谁做的？可能是用户、管理员、系统进程
- 客体：对什么做的？某个文件、数据库记录、配置项
- 操作：做了什么？增、删、改、查、登录、授权
- 结果：成功还是失败？失败原因是什么？
我个人习惯：在设计审计日志时，一定要把“结果”字段细化——不光记录成功/失败，还要记录失败的具体原因（比如“密码错误次数超限”）。这样排查问题时能省去不少功夫。
1.2 审计日志的重要性
你可能会问：“不就是多存几条记录吗，有那么重要？” 嗯，这话我在项目初期也说过。直到有一次线上事故让我彻底改观。
第一，合规要求。很多行业都有强制规定。像金融、医疗、政务系统，监管机构明确要求保留一定期限的操作日志。没有审计日志，过审基本免谈。
第二，安全溯源。系统被入侵了怎么办？这时候审计日志就是“黑匣子”。它能告诉你攻击者从哪进来的、动了哪些数据。我在处理过一次数据泄露事件后，对这一点深有体会。
第三，故障排查。有时候业务出问题了，开发人员互相推锅——“肯定是你的代码改的”。审计日志能客观还原操作顺序，谁在什么时间改了配置，一目了然。
第四，内部审计。防止“监守自盗”。我记得有个客户，他们的DBA（数据库管理员）私自导出了用户数据去卖。幸好系统完整记录了每一次数据导出操作，直接锁定了证据。
| 场景 | 没有审计日志 | 有审计日志 |
|---|---|---|
| 合规检查 | 无法通过，面临罚款 | 轻松过审，证明充分 |
| 安全事件 | 找不到攻击痕迹 | 精确溯源，快速响应 |
| 配置回滚 | 靠“人肉记忆”猜 | 秒级定位变更点 |
| 数据泄露 | 找不到责任人 | 完整证据链 |
1.3 常见审计日志类型
不同类型的系统，审计日志的侧重点也不同。我简单总结了几类常见的：
按系统层级划分：
- 数据库审计日志：记录SQL执行、表结构变更、用户权限变化。我曾经遇到过一个问题：线上某个表突然被删了，靠的就是MySQL的general log找到了执行人。
- 服务器操作审计：SSH登录、命令执行、文件操作。Linux的auditd就是干这个的。
- 应用层审计：用户登录、业务操作、敏感数据访问。这层最复杂，也最容易被忽略。
- 网络设备审计：防火墙规则变更、VPN连接、路由器配置。
你想想看，一个大型系统可能同时产生这几种日志。如果每个类型都自己写存储逻辑，写入压力很快就会出现瓶颈——这正好是我们后续要讨论的QPS评估的基础。
我曾经踩过的坑：某次把应用层审计日志和普通业务日志写到同一个表里。结果业务高峰期，审计日志量直接暴涨，拖垮了数据库。后来才学会“审计日志必须独立存储”这个基本原则。
下面这张图能帮你理清审计日志的核心要素和它们之间的关系：
图中你可以看到，审计日志的四要素构成了它的完整记录。而不同类型的审计日志，最终都会面临一个共同问题——写入QPS（每秒查询率）。这就是我们这门课要讲的核心。
好了，审计日志的基本概念就聊到这。搞清楚了“什么是审计日志”，我们才能真正理解为什么QPS评估如此重要——毕竟，一个连基本概念都没吃透的人，很难设计出高性能的审计系统。你说对吧？