4. 变更记录数据结构：核心字段与数据模型设计
变更记录是归档包权限配置审计追踪的核心载体。每一次权限的授予、撤销、修改，都必须生成一条不可篡改的变更记录，用于后续的合规审查、问题回溯与责任认定。本节将详细拆解变更记录的核心字段定义与数据模型设计原则。
4.1 变更记录核心字段
一条标准的变更记录应包含以下五类核心信息，缺一不可：
| 字段类别 | 字段名称 | 类型 | 说明与示例 |
|---|---|---|---|
| 操作人 | operator_id | string (UUID) | 执行操作的用户唯一标识，如 a1b2c3d4-... |
| operator_name | string | 操作人姓名/工号，如 zhangsan 或 张三 |
|
| 时间 | operated_at | datetime (ISO 8601) | 操作发生的精确时间戳，如 2025-03-21T14:30:00Z |
| 操作类型 | action_type | enum | CREATE / UPDATE / DELETE / REVOKE / GRANT |
| 变更前值 | old_value | json / text | 操作前的完整权限快照或关键字段值 |
| 变更后值 | new_value | json / text | 操作后的完整权限快照或关键字段值 |
| 关联对象 | resource_id | string | 被修改的归档包或权限条目 ID |
| resource_type | string | 资源类型，如 archive_package / permission_entry |
设计要点： old_value 与 new_value 建议使用 JSON 格式存储，以支持结构化的权限数据对比。对于敏感字段（如密码、密钥），应在存储前进行脱敏或哈希处理，避免明文泄露。
4.2 数据模型设计
基于上述核心字段，推荐采用以下关系型数据模型（以 PostgreSQL 为例）。该模型兼顾了查询效率、数据完整性与扩展性。
-- 变更记录主表
CREATE TABLE audit_change_log (
id BIGSERIAL PRIMARY KEY,
operator_id UUID NOT NULL,
operator_name VARCHAR(64) NOT NULL,
operated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
action_type VARCHAR(20) NOT NULL CHECK (action_type IN ('CREATE','UPDATE','DELETE','REVOKE','GRANT')),
resource_id VARCHAR(128) NOT NULL,
resource_type VARCHAR(64) NOT NULL,
old_value JSONB,
new_value JSONB,
comment TEXT, -- 操作备注/原因
request_id UUID, -- 关联请求追踪 ID
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
-- 索引设计：加速按资源与时间查询
CREATE INDEX idx_change_log_resource ON audit_change_log(resource_id, resource_type);
CREATE INDEX idx_change_log_operator ON audit_change_log(operator_id);
CREATE INDEX idx_change_log_time ON audit_change_log(operated_at DESC);
CREATE INDEX idx_change_log_action ON audit_change_log(action_type);
模型优势：
- JSONB 字段：支持任意结构的权限快照，无需频繁修改表结构。
- 时间戳索引：按 operated_at DESC 排序，可高效获取最新变更记录。
- 资源复合索引：快速定位某个归档包或权限条目的所有历史变更。
- 操作类型枚举：约束数据一致性，避免脏数据写入。
4.3 变更记录数据流与字段关系
下图展示了从用户发起操作到生成完整变更记录的数据流转过程，以及各核心字段在流程中的位置与作用：
4.4 字段设计避坑指南
- 避免使用 VARCHAR 存储 JSON：应使用 JSONB 类型，支持索引与部分更新，避免全量字符串解析。
- 操作类型不要用自由文本：必须使用枚举或 CHECK 约束，防止拼写错误导致查询失效。
- 时间戳统一使用 UTC：所有 operated_at 字段强制使用 UTC 时间，避免时区混乱。
- 变更前后值不可省略：即使是 DELETE 操作，也必须记录 old_value；CREATE 操作则 new_value 为完整值，old_value 为 NULL。
- 关联请求 ID：建议增加 request_id 字段，将一次批量操作的所有变更记录关联起来，便于整体回滚审查。
常见错误： 部分实现仅记录“变更后值”而忽略“变更前值”，导致无法回退到上一状态。务必同时保留 old_value 与 new_value，确保双向追溯能力。
4.5 变更记录与审查意见的关联模型
在实际业务中，变更记录往往需要与审查意见（Review Comment）进行关联。下图展示了变更记录与审查意见之间的数据关系：
通过上述模型，审查人员可以针对某一条具体的变更记录发表意见，系统也能快速查询某次变更的所有审查反馈，形成完整的审计闭环。