smart
67837df8d0
- 新增全套考试卷、评估卷、参考答案与考试培训包模板 - 修正slidev培训课件：调整模块标题、链路图缩放，替换工单示例为通用业务对象 - 修正课堂红线表述为证据红线，将小组作业调整为个人作业要求 - 新增权限、状态流转、审计日志、看板指标四类可复用业务规则块 - 整理AI工程技能交付包，迁移旧资产至客户专属交付包并统一术语 - 新增考试输出模板与TRAE使用记录文档
124 lines
3.8 KiB
Markdown
124 lines
3.8 KiB
Markdown
# 模块 4：审计日志设计
|
|
|
|
<div class="mt-6 text-sm">
|
|
|
|
工单是多人协作过程。关键动作必须能回答：谁、什么时候、对哪个工单、改了什么、结果如何。
|
|
|
|
</div>
|
|
|
|
<div class="grid grid-cols-3 gap-4 mt-8 text-sm">
|
|
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30 text-center">指派</div>
|
|
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-center">状态变更</div>
|
|
<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-center">优先级变更</div>
|
|
<div class="p-3 rounded-xl bg-purple-500/10 border border-purple-500/30 text-center">驳回</div>
|
|
<div class="p-3 rounded-xl bg-red-500/10 border border-red-500/30 text-center">关闭</div>
|
|
<div class="p-3 rounded-xl bg-gray-500/10 border border-gray-500/30 text-center">删除</div>
|
|
</div>
|
|
|
|
<!--
|
|
审计日志不是一句“修改了工单”。
|
|
指派、状态变更、优先级变更、驳回、关闭、删除都应该能追溯。
|
|
-->
|
|
|
|
---
|
|
|
|
# 审计日志字段表
|
|
|
|
<div class="mt-5 text-xs">
|
|
|
|
| 字段 | 含义 | 示例 |
|
|
|---|---|---|
|
|
| ticket_id | 工单 ID | WO-001 |
|
|
| operator | 操作人 | zhangsan |
|
|
| action | 操作动作 | assign / transition / edit |
|
|
| field_name | 字段名 | status / assignee |
|
|
| before_value | 修改前 | processing |
|
|
| after_value | 修改后 | pending_verify |
|
|
| result | 操作结果 | success / fail |
|
|
| operate_time | 操作时间 | 2026-06-29 10:00 |
|
|
| remark | 备注 | 提交验证说明 |
|
|
|
|
</div>
|
|
|
|
<!--
|
|
字段前后值是审计日志的关键。
|
|
如果只记录“用户修改了工单”，后续追责和排查都很困难。
|
|
-->
|
|
|
|
---
|
|
|
|
# 详情页操作记录
|
|
|
|
<div class="mt-5 text-sm">
|
|
|
|
| 展示字段 | 说明 |
|
|
|---|---|
|
|
| 操作时间 | 按时间倒序 |
|
|
| 操作人 | 当前登录用户 |
|
|
| 动作 | 指派、提交验证、驳回、关闭 |
|
|
| 变更内容 | status: processing -> pending_verify |
|
|
| 备注 | 处理说明、驳回原因 |
|
|
| 结果 | success / fail |
|
|
|
|
</div>
|
|
|
|
<!--
|
|
审计日志不只是后端写入，还要能在工单详情页被查看。
|
|
课堂验收时至少完成一次指派、一次提交验证、一次驳回，并能看到三条记录。
|
|
-->
|
|
|
|
---
|
|
|
|
# 审计日志 SOP
|
|
|
|
<div class="mt-5 text-sm">
|
|
|
|
```md
|
|
必须记录：
|
|
新增、编辑、删除、指派、状态变更、优先级变更、驳回、关闭。
|
|
|
|
展示位置：
|
|
工单详情页操作记录区域。
|
|
|
|
事务要求：
|
|
状态更新和日志写入在同一业务事务内完成。
|
|
|
|
验收：
|
|
执行状态变更、指派、驳回、关闭后，详情页能看到对应审计记录。
|
|
```
|
|
|
|
</div>
|
|
|
|
<!--
|
|
状态更新成功但日志失败，或者日志成功但状态失败，都会造成追溯问题。
|
|
所以 Service 层要明确事务边界。
|
|
-->
|
|
|
|
---
|
|
|
|
# 可直接复制到 rules：审计日志
|
|
|
|
<div class="mt-5 text-xs">
|
|
|
|
```md
|
|
## 关键业务操作必须写审计
|
|
- 级别：硬约束
|
|
- 适用场景：创建、编辑关键字段、指派、状态流转、驳回、关闭、删除、导出、权限变更。
|
|
- 必须：记录 actor、action、target_id、old_value、new_value、source、request_id、created_at 或项目等价字段。
|
|
- 禁止：只记录普通日志而没有业务审计；操作失败后写成功审计。
|
|
- 验收方式：执行关键操作后可查询审计记录，字段与实际变更一致。
|
|
|
|
## 审计和业务写入必须一致
|
|
- 必须：明确审计写入时机、事务关系、失败处理和重试策略。
|
|
- 禁止：业务成功审计丢失，或审计成功但业务失败。
|
|
- 验收方式：模拟业务失败和审计失败，结果符合一致性策略。
|
|
```
|
|
|
|
</div>
|
|
|
|
<!--
|
|
审计规则要比“记录日志”具体得多。
|
|
课堂里可以让学员检查：有没有 old/new value，有没有 request_id 或来源，有没有失败行为说明，事务失败时审计和业务数据是否一致。
|
|
如果这些说不清，审计日志就不能作为上线后的追溯依据。
|
|
-->
|