# DATA_RETENTION_AND_DELETION 最后更新: 2026-06-14 ## 1. 目标 定义 T12 用户端 Web 自助 MVP 的最小数据保留与删除规则,确保“可删除”不是口头承诺。 ## 2. 数据分类与建议保留期 | 数据类型 | 示例 | 建议保留期 | 删除方式 | | ------------ | --------------------------- | ----------------------- | -------------------------- | | 订单主数据 | orders 表、状态、金额、套餐 | 服务完成后 180 天 | 逻辑受理 + 物理删除/匿名化 | | 资料提交数据 | `order_intakes` payload | 服务完成后 180 天 | 与订单一起删除 | | 报告交付文件 | HTML/PDF 报告 | 服务完成后 180 天 | 删除文件并清理路径 | | 通知审计 | `delivery_notifications` | 服务完成后 180 天 | 随订单删除或单独清理 | | 支付审计 | 支付单/回调记录 | 至少 180 天,争议中延长 | 审计期结束后清理 | | 系统日志 | 服务日志/错误日志 | 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 报告文件 - `order_deletion_audits` 最小审计表 - `scripts/gaokao_retention_cleanup.py` / `scripts/gaokao-retention-cleanup.py` 保留期清理入口 - `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` 尚缺: - 前台/客服删除工单流程 - 更细粒度的匿名化策略(如案例长期保留脱敏版) - 目标生产主机上的实际安装/值班留痕(仓库内只有调度样例,不代表已部署) ## 5. MVP 最低执行要求 上线前至少做到: 1. 用户能知道可申请删除 2. 内部 runbook 明确谁来删、删哪些表和文件 3. 删除后要复核文件路径已不存在 4. 不能把“仅删数据库”误报成“数据已全部删除” ## 6. 最小调度与 runbook 仓库当前给出的最小执行口径: - 人工指定 cutoff:`python3 scripts/gaokao-retention-cleanup.py --cutoff --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` 真相边界:当前保留期作业执行的是后台匿名化,不应误报成“用户删除请求流程已经完整上线”。