操作审计

本文是“操作审计”模块的规划与持续维护入口。当前内容用于确定模块边界、教学路线和代码框架，不表示所有功能已经开发或验证完成。后续每完成并验证一个小功能，再逐步补充实现代码、逐行解释、测试结果和常见问题。

文档版本	v0.2.0
更新时间	2026-08-26 11:34:30 +0800
本次更新	产品和项目正式由 devops（旧名） 更名为 devopsX，同步调整项目根路径和相关框架名称；博客分类 Python / devops 保持不变。
当前状态	模块规划稿，功能尚未开始或尚未全部验证
Django App	audit

1 模块定位

负责汇总平台关键操作、安全事件和业务变更，提供统一查询和追踪能力。各模块仍保留自己的领域记录，audit 保存跨模块审计事件而不是复制所有业务表。

1.1 模块目标

• 统一记录谁在何时对什么资源执行了什么操作。
• 保存请求来源、结果和必要的变更摘要。
• 支持按用户、模块、资源和时间检索。
• 防止敏感信息进入审计内容。
• 为安全排查和合规追踪提供稳定证据。

1.2 顺序不是固定合同

本文中的功能顺序只表示当前推荐的学习路线，不是永久不变的产品编号。以后可以在本模块中插入新的功能，也可以在整个平台中增加新的独立模块，不需要重命名本文、重排其他文章标题或重构其他 Django App。

2 模块边界

2.1 本模块负责

• 登录与安全事件
• 业务操作事件
• 资源变更摘要
• 查询与导出
• 保留策略
• 跨模块关联

2.2 本模块不负责

• 完整业务数据副本
• SSH 会话录像主体
• 监控时序数据
• 应用日志平台

边界的目的不是阻止模块协作，而是避免一个 App 直接承担其他 App 的业务职责。跨模块需求应通过公开服务、API、事件或稳定标识完成。

3 代码位置与目录规划

本模块使用稳定的 Django App 名称 audit。开始教学时先保留 Django 默认文件，只有代码真实增长后才拆分 services、api 或 tests 等目录。

C:\Users\lizexiong\devopsX
└── audit
    ├── __init__.py
    ├── admin.py
    ├── apps.py
    ├── models.py
    ├── tests.py
    ├── urls.py             # 需要页面路由时再创建
    ├── views.py
    ├── migrations
    │   └── __init__.py
    └── templates
        └── audit           # 模板 namespace

3.1 最小接入点

新增业务模块时，只应增加自己的 App、URL namespace、模板 namespace、权限前缀和必要的平台注册项。根配置允许增加少量明确的注册代码，但不能要求修改其他业务 App 的内部文件。

3.2 不提前制造复杂目录

文章展示的是发展方向，不要求第一节一次创建完整目录。初期优先使用 Django 默认生成的文件；只有 models.py、views.py、tests.py 等文件真实变大后，才按职责拆分。

4 候选数据模型

下面是当前候选模型，用于帮助理解领域，不代表第一节全部创建。每个模型都需要在对应功能开始时再次验证是否必要。

模型或能力	职责
AuditEvent	统一事件，包含用户、模块、动作、资源、结果和时间。
AuditChange	必要时保存经过脱敏的字段变更摘要。
LoginEvent	如果登录事件需要独立检索，可作为专门事件类型。
ExportRecord	记录审计数据导出人、范围和结果。

5 当前功能路线

下面是当前推荐路线。以后可以增加、删除或调整某一步，而不影响其他模块文章和 App 结构。

当前顺序	功能	状态
1	创建 audit App	按当前学习进度逐步确定
2	定义统一审计事件结构	按当前学习进度逐步确定
3	记录登录成功和失败	按当前学习进度逐步确定
4	记录用户与权限变更	按当前学习进度逐步确定
5	记录 CMDB 资产变更	按当前学习进度逐步确定
6	记录自动化和发布操作	按当前学习进度逐步确定
7	记录 Kubernetes 变更	按当前学习进度逐步确定
8	实现审计查询和分页	按当前学习进度逐步确定
9	实现受控导出	按当前学习进度逐步确定
10	制定脱敏和保留策略	按当前学习进度逐步确定
11	增加事件完整性测试	按当前学习进度逐步确定

6 与其他模块的协作契约

• 各模块通过统一审计服务或事件接口提交数据，避免直接写 audit 模型内部字段。
• 审计事件使用稳定资源类型和资源 ID，不反向依赖业务模型类。
• 敏感凭证、密码、Token、完整命令输出和大文件不得写入通用审计字段。

6.1 避免内部耦合

其他 App 不应导入本模块的视图、表单或私有服务，也不应直接修改本模块数据库表。确实需要协作时，先定义最小公开接口；只有多个模块已经出现相同需求后，才考虑把稳定能力抽取到 common。

7 独立扩展规则

• 文章标题不依赖固定的全局数字编号。
• 文章内部继续使用 1、1.1、1.1.1 的标题层级。
• 模块使用稳定的 App 名称、URL namespace、模板 namespace 和权限前缀。
• 每个 App 管理自己的模型、迁移、服务、页面和测试。
• 新增未知模块时，新建自己的文章和 App，不重排现有文章和目录。
• 推荐学习顺序可以变化，但稳定标识和模块边界不能随意变化。
• 不为“未来可能需要”提前建设复杂插件系统；先用 Django 明确的注册点保持低耦合。

8 教学与练习方式

本模块后续每个小功能都按以下方式展开：

本节目标
→ 知识背景
→ 当前工作目录
→ 文件清单和完整路径
→ 完整命令与代码
→ 逐行或逐段解释
→ 执行流程和设计原因
→ 运行验证
→ 常见错误与调试
→ 跟随、修改、填空、独立和排错练习
→ 完成后的目录树
→ 等待用户反馈

默认由用户亲手创建文件、输入代码并执行命令。除非用户明确要求代为操作，否则不自动一次写完整个模块。

9 模块验收标准

• 关键操作可以按用户和资源追踪
• 失败操作同样被记录
• 敏感字段被可靠脱敏
• 普通用户不能查看或导出审计数据
• 业务对象删除后审计事件仍可解释

只有具体功能通过相应测试和实际操作验证后，才把它标记为完成并整理为可复现教程。规划、候选模型和未来路线不能被描述为已经实现。

10 当前状态与维护方式

当前文章已完成模块边界和路线规划，具体代码将随着实际开发逐步补充。后续修改遵循以下原则：

• 用户在 Python / devops 分类中维护文章入口；
• 每次完成并验证功能后，更新对应文章正文；
• 架构变化时先判断影响范围，再更新 Skill 和相关模块文章；
• 只修改真正受影响的模块，不因为增加一个模块而批量重写其他文章；
• 文章可以持续优化，但必须保留准确的状态说明。