解读

面试官想验证两点：

1. 你是否理解 GDPR“被遗忘权”在中国出海业务中的法律强制性与时效性（72 小时内响应）。
2. 你是否能把“擦除”拆解成数据定位→不可恢复删除→残留清理→可审计证明四步，并给出在 Cloud SQL 内部可落地的技术方案，而不是泛泛而谈“删库跑路”。

知识点

• GDPR 第 17 条“Right to Erasure”：要求“不可过度延迟”地删除可识别个人数据，含备份、副本、日志。
• Cloud SQL 数据分布：主实例、只读副本、自动备份、PITR 事务日志、慢查询日志、审计日志、磁盘快照、Cloud Storage 导出文件。
• 删除粒度：行级删除优于整库删除，需配合IAM 细粒度权限与临时提升权限机制，防止误操作。
• 不可恢复：在 Google 侧需使用CMEK（客户管理的加密密钥）密钥销毁实现物理不可恢复；在应用侧需覆写+随机密钥再删除满足国内《个人信息保护法》第 47 条“去标识化”要求。
• 审计闭环：必须输出Data Erasure Report，含请求 ID、删除范围、SQL 指纹、密钥版本、执行人、时间戳，并写入Cloud Logging 专用日志桶保存 3 年，供欧盟监管机构或国内网信办抽查。

答案

收到 GDPR 删除请求后，我按“六步闭环”执行：

1. 请求合法性校验
   用内部工单系统核对数据主体身份、请求范围、时效，生成唯一GDPR-ID，并创建 JIRA 子任务，责任人设为Data Protection Officer（DPO）。

2. 数据定位与影响评估
   通过Data Catalog + Cloud SQL Insights扫描全实例，定位个人数据所在库、表、分区；输出个人数据分布图，评估是否涉及跨区域副本（如 europe-west1 到 asia-northeast1），并计算删除对业务事务量的影响。

3. 行级安全删除
   在主实例开启read-only 事务，使用WHERE user_id = ‘GDPR-ID’执行DELETE；随后立即执行**VACUUM FULL（PostgreSQL）或OPTIMIZE TABLE（MySQL）**释放页，防止 MVCC 残留。

4. 备份与日志链清理
   a) 关闭自动备份 1 个周期，防止新备份含目标数据；
   b) 对保留周期内的自动备份调用gcloud sql backups delete，并记录备份 ID；
   c) 若启用PITR，删除包含删除点之后所有事务日志；
   d) 将慢查询日志、audit_log中相关条目通过LOG_BUCKET 生命周期规则提前置过期，或调用DLP API做crypto-shred替换。

5. 物理不可恢复
   若实例使用CMEK，调用gcloud kms keys versions destroy销毁密钥版本，使磁盘块不可解密；若使用 Google 默认加密，则至少执行磁盘零写：通过创建新实例并导入干净数据，再删除旧实例并勾选**“擦除磁盘”，等待 Google 后台cryptographic erasure**。

6. 审计与回执
   在Cloud Logging创建专用日志桶gdpr_erase，写入 JSON 格式的Data Erasure Report，含 GDPR-ID、执行的 SQL 指纹、删除行数、密钥版本、执行人 OIDC token、时间戳；同时向数据主体发送Machine-readable confirmation，并在24 小时内同步到欧洲代表处备案。

拓展思考

• 中国出海业务双合规：GDPR 删除后，若数据同时落在中国境内备份，需再走一次《个人信息保护法》第 47 条**“删除或去标识化”**流程，避免国内监管认为“数据出境后未同步删除”。
• 大规模删除性能：单表超 5 亿行时，DELETE会触发长事务锁，可改用分区表+DROP PARTITION或pg_partman提前按用户哈希分区，实现秒级删除。
• 零停机方案：利用Cloud SQL 蓝绿发布：先绿实例执行删除，校验无误后通过Cloud SQL Auth Proxy切换连接串，实现用户无感知。