3. 请求登记与分类：工单系统录入、请求类型分类、紧急程度标记
好，我们进入实操环节的第三步。这一步说白了，就是把用户那个「我要删数据」的诉求，变成工单系统里一条可追踪、可审计、可分配任务的记录。
我见过不少团队，这一步做得特别糙。用户发一封邮件，客服回一句「好的」，然后就没了下文。等监管来查，或者用户投诉说「我三个月前就申请了你们怎么还没处理」，你连个凭证都拿不出来。嗯，这其实是个合规风险。
3.1 工单系统录入：别让请求「飘」在外面
我个人习惯，所有数据删除请求必须进工单系统。不管是用户通过什么渠道来的——邮件、在线客服、电话、甚至纸质信函——最终都要落成一张工单。
工单里至少要有这几个字段：
| 字段名 | 说明 | 示例 |
|---|---|---|
| 请求编号 | 全局唯一，自动生成 | DEL-20250321-0042 |
| 请求来源 | 邮件/电话/在线表单/API | 邮件 |
| 用户标识 | 用户ID、手机号或邮箱 | user_123456 |
| 请求时间 | 精确到秒 | 2025-03-21 14:32:18 |
| 请求类型 | 完全删除/部分删除/匿名化 | 完全删除 |
| 紧急程度 | 普通/紧急/特急 | 普通 |
| 当前状态 | 待处理/处理中/已完成/已驳回 | 待处理 |
| 处理人 | 分配给谁 | 张三 |
我在项目中遇到过，有些公司用Excel表格来管。说实话，小规模还行，一旦每天几十上百个请求，Excel根本扛不住。而且Excel没有权限控制，谁都能改，审计的时候就是个灾难。
3.2 请求类型分类：完全删除、部分删除、匿名化
用户说「我要删数据」，但具体删什么？这里头门道很多。我一般把请求分成三类：
3.2.1 完全删除
这个最好理解。用户要求把他的所有个人数据从你的系统里抹掉。注意，是「所有」。包括主数据库、备份库、日志、缓存、甚至归档数据。
但这里有个坑——你不能真的把数据库里那条记录直接DELETE掉。为什么？因为你的业务系统可能还有关联数据，比如订单记录、交易流水。你把用户信息删了，订单表里那个user_id就变成孤魂野鬼了。
3.2.2 部分删除
用户可能只想删某一部分数据。比如「把我的手机号删了，但保留我的昵称和头像」。或者「删掉我去年之前的浏览记录」。
这种请求最麻烦。你得搞清楚用户到底想删什么，而且不能删错。我建议在工单里加一个「删除范围」字段，让用户勾选或者填写。
// 部分删除的伪代码示例
function partialDelete(userId, fieldsToDelete) {
const allowedFields = ['phone', 'email', 'address', 'browsing_history'];
// 校验：只允许删除白名单内的字段
const safeFields = fieldsToDelete.filter(f => allowedFields.includes(f));
if (safeFields.length === 0) {
throw new Error('没有可删除的字段');
}
// 执行删除（置空或脱敏）
for (const field of safeFields) {
await db.collection('users').updateOne(
{ user_id: userId },
{ $set: { [field]: null } }
);
}
}3.2.3 匿名化
这个比较特殊。用户不要求删除数据，但要求把他的数据变成无法识别到具体个人的状态。说白了，就是把「张三，138xxxx」变成「用户A，138****」。
匿名化之后的数据，通常可以继续用于统计分析、模型训练等场景。但要注意，匿名化必须是不可逆的。你不能留一份原始数据在某个角落里。
3.3 紧急程度标记：别让重要请求被淹没
不是所有删除请求都同等紧急。我个人习惯把紧急程度分成三档：
- 普通： 常规的删除请求，比如用户想清理一下历史数据。处理时限可以放宽到7-15天。
- 紧急： 涉及敏感数据泄露风险，或者用户明确表示「我的数据被滥用了，立刻删」。处理时限建议24-48小时。
- 特急： 涉及法律诉讼、监管调查、或者用户是VIP/公众人物。处理时限建议4-8小时。
你想想看，如果所有请求都按先来后到处理，一个普通用户的删除请求排在一个特急请求前面，那特急请求可能就耽误了。所以工单系统里一定要有紧急程度排序功能。
我在项目中遇到过，有一次一个知名博主公开投诉我们公司不处理他的删除请求。后来一查，他的请求其实早就提交了，但被淹没在几百个普通请求里，没人注意到。从那以后，我们加了一个自动标记规则——如果用户是认证的公众人物，或者请求内容包含「律师函」「投诉」「监管」等关键词，自动标记为紧急。
3.4 实操检查清单
好了，这一步做完之后，我建议你对照这个清单自查一下：
- 所有渠道的删除请求是否都统一录入了工单系统？
- 工单是否包含了用户标识、请求类型、紧急程度等关键字段？
- 是否区分了完全删除、部分删除和匿名化？
- 紧急程度标记是否有明确的规则和升级机制？
- 工单的流转记录是否可审计？
嗯，这一步看起来简单，但其实是整个删除流程的「地基」。地基没打好，后面处理得再快再准，也容易出乱子。我个人建议，花点时间把工单模板和分类规则定好，后面能省很多心。