82 lines
4.3 KiB
Markdown
82 lines
4.3 KiB
Markdown
# DATA_RETENTION_AND_DELETION
|
||
|
||
最后更新: 2026-06-14
|
||
|
||
## 1. 目标
|
||
|
||
定义 T12 用户端 Web 自助 MVP 的最小数据保留与删除规则，确保“可删除”不是口头承诺。
|
||
|
||
## 2. 数据分类与建议保留期
|
||
|
||
| 数据类型 | 示例 | 建议保留期 | 删除方式 |
|
||
| -------------- | ------------------------------------ | ----------------------- | -------------------------------------- |
|
||
| 订单主数据 | orders 表、状态、金额、套餐 | 服务完成后 180 天 | 逻辑受理 + 物理删除/匿名化 |
|
||
| 资料提交数据 | `order_intakes` payload | 服务完成后 180 天 | 与订单一起删除 |
|
||
| 报告交付文件 | HTML/PDF 报告 | 服务完成后 180 天 | 删除文件并清理路径 |
|
||
| 通知审计 | `delivery_notifications` | 服务完成后 180 天 | 删除时物理清除；匿名化时 payload 置空 |
|
||
| 支付审计 | 支付单/回调记录 | 至少 180 天，争议中延长 | 审计期结束后清理 |
|
||
| 删除申请日志 | `deletion-requests.jsonl` | 随订单 retention 同步 | retention 作业按候选订单移除日志项 |
|
||
| 分享访问遥测 | `share_link_access_events` | 随订单 retention 同步 | retention 作业删除对应 report_id 事件 |
|
||
| 系统日志 | 服务日志/错误日志 | 30~90 天 | 日志轮转清理 |
|
||
| 脱敏案例数据 | 仅用于内部复盘 | 长期，但必须脱敏 | 仅保留脱敏版 |
|
||
|
||
## 3. 删除请求处理原则
|
||
|
||
用户申请删除时：
|
||
|
||
1. 先确认订单号与身份渠道
|
||
2. 判断是否处于以下保留例外：
|
||
- 退款争议处理中
|
||
- 支付/审计必要期间
|
||
- 法律或投诉处理必要期间
|
||
3. 如无保留例外：
|
||
- 删除订单主数据
|
||
- 删除资料提交记录
|
||
- 删除报告 HTML/PDF 文件
|
||
- 删除关联通知记录
|
||
- 删除申请日志 / 分享访问遥测中的对应订单旁路记录
|
||
4. 在审计记录中留下“已删除/已匿名化”的最小操作痕迹
|
||
|
||
## 4. 当前系统能力与缺口
|
||
|
||
已具备：
|
||
|
||
- `OrdersDAO.delete()` 删除订单能力
|
||
- ON DELETE CASCADE 清理部分关联表
|
||
- 后台 `DELETE /api/orders/{id}?mode=delete|anonymize&reason=...` 最小执行入口
|
||
- 删除时自动清理 HTML/PDF 报告文件与 portal 上传附件
|
||
- 匿名化时同步清空 `delivery_notifications.payload_json`
|
||
- `order_deletion_audits` 最小审计表
|
||
- `scripts/gaokao_retention_cleanup.py` / `scripts/gaokao-retention-cleanup.py` 保留期清理入口
|
||
- retention 作业会同步修剪 `deletion-requests.jsonl` 与 `share_link_access_events`
|
||
- `scripts/gaokao-retention-cleanup.py --retention-days 180` 最小定时调度入口
|
||
- `docs/DELIVERY_RETENTION_OPS_RUNBOOK.md`
|
||
- `deploy/systemd/gaokao-retention-cleanup.{service,timer}`
|
||
- `deploy/cron/gaokao-jobs.crontab`
|
||
|
||
尚缺：
|
||
|
||
- 前台/客服删除工单流程仍是 portal 提交 + 后台处理，不是全自动闭环
|
||
- 更细粒度的匿名化策略（如案例长期保留脱敏版）
|
||
- 目标生产主机上的实际安装/值班留痕（仓库内只有调度样例，不代表已部署）
|
||
|
||
## 5. MVP 最低执行要求
|
||
|
||
上线前至少做到：
|
||
|
||
1. 用户能知道可申请删除
|
||
2. 内部 runbook 明确谁来删、删哪些表和文件
|
||
3. 删除后要复核文件路径已不存在
|
||
4. 不能把“仅删数据库”误报成“数据已全部删除”
|
||
|
||
## 6. 最小调度与 runbook
|
||
|
||
仓库当前给出的最小执行口径：
|
||
|
||
- 人工指定 cutoff：`python3 scripts/gaokao-retention-cleanup.py --cutoff <ISO8601> --dry-run`
|
||
- 定时调度：`python3 scripts/gaokao-retention-cleanup.py --retention-days 180`
|
||
- runbook：`docs/DELIVERY_RETENTION_OPS_RUNBOOK.md`
|
||
- systemd/cron 样例：`deploy/systemd/gaokao-retention-cleanup.{service,timer}` / `deploy/cron/gaokao-jobs.crontab`
|
||
|
||
真相边界：当前保留期作业执行的是后台匿名化，并同步修剪删除申请日志/分享访问遥测；这仍不应误报成“用户删除请求流程已经完整上线”。
|