审计能力

审计表重构：12 个字段与三级留存口径

2026 年 10 月 30 日，快连完成审计表重构。字段从 7 个扩到 12 个，新增部门编码、设备指纹摘要、动作耗时、网关编号与摘要值五个字段；写入路径保持只追加，检索耗时从 1.8 秒压到 0.4 秒。这次重构的目标不是记更多，而是记更准。

一、旧表的三个问题

旧审计表只有 7 个字段：事件编号、时间、主体、资源、动作、结果码、客户端版本。字段少带来的第一个问题是没法做部门维度统计——同一个主体跨部门调动后，历史记录无法归属到当时的部门。

第二个问题是无法核验完整性。旧表允许运维在故障排查时临时修改结果码，虽然每次修改都留了操作人，但这本身就破坏了「审计记录不可改」的原则。

第三个问题是检索慢。旧表按时间单列建索引，按主体查询要走全表扫描，1.2 亿行存量下平均 1.8 秒，超出可接受范围。

二、12 个字段是怎么定的

新表的 12 个字段按「谁、何时、对什么、做了什么、结果如何、能否核验」六个维度铺开。前 11 个字段承载信息，第 12 个字段承载校验。

设备指纹摘要用不可逆哈希，只用于识别「同一台设备」而不是「哪台设备」。这一项企业可以关闭——关闭后异常登录识别会退化为按 IP 判断，准确率下降但隐私更强。

摘要值 digest 的计算方式是：按 event_id 顺序把前 11 个字段序列化后做 SHA-256，取前 16 字节的十六进制表示。核验时重算一遍即可发现任何原地修改，成本是每百万行约 4 秒。

三、写入与检索的性能数据

写入路径改为只追加后，数据库层对审计表只授予 INSERT 与 SELECT 权限，UPDATE 与 DELETE 权限被回收。清理走独立的清理任务，任务本身写一条批次记录。

检索方面，新增了（actor_id, ts）联合索引与（result, ts）联合索引。压测条件是单网关 2000 并发会话、存量 1.2 亿行、查询条件为「主体 + 7 天时间窗」，平均耗时从 1.8 秒降到 0.4 秒。

写入性能没有因为字段变多而下降：单条记录写入耗时中位 3.4ms，P99 为 11.2ms。灰度期间审计写入队列的最大积压为 1,840 条，持续 40 秒后回落。

四、三级留存与清理实测

留存提供 30 天、90 天、180 天三档，企业可在策略文件中指定。默认 30 天。清理任务在到期次日 03:00 执行，先按时间范围批量删除，再对存储块执行覆写，最后写一条批次记录。

2026 年 9 月的一次全量清理中，删除 1,842,903 行记录耗时 47 分钟。清理后核对源表计数与删除清单行数完全一致，批次记录包含批次号、起止时间、删除行数与执行节点四项。

需要提醒的是：留存周期越短，排障回溯窗口越短。如果企业有季度审计要求，选 90 天；有半年期审计要求，选 180 天。切换周期后，超出新周期的历史数据会在下一个清理批次被删除，这个动作不可逆。