数据留多久、到期去哪：vibe 项目的数据留存策略实战

账单涨了三倍、用户要删的数据删不掉：先讲一个虚构的教训

先讲一个虚构的教学例子。老周一个人用 AI 搭了个工单系统“云帆工单”，上线第一年跑得很顺：客户提工单、客服回工单、工单关单，一切正常。到了第二年，他收到两件事。第一件是云服务商的账单：数据库的账单比上个月涨了三倍，存储那一栏写着 2.1TB——他打开一看，系统上线第一天起的每一条操作日志、每一次登录记录、每一个已经关单三年的工单附件，全都原样躺在最贵的那块热存储上，从来没有人清理过。第二件是一位客户的邮件：“请删除我们公司 2024 年之前的所有聊天记录，我们的法务要求留存期只有两年。”老周去查代码，发现聊天记录根本没有留存期这个概念：删，只能整条整条手动删；更糟的是，他发现备份里还躺着三年前的全量快照，就算把线上数据删了，备份一恢复，数据又回来了。

老周花了一个月才收拾完这个烂摊子：写脚本分批清理日志、给不同数据定留存期、给备份加过期策略、给客户出一份书面的留存说明。那一个月里他最常说的一句话是：“早知道上线第一天就该定好。”数据留存就是这样一种工作：不做的时候感觉不到它存在，一旦出问题，修起来的成本比当初定规则高十倍——要么是存储账单失控，要么是法务找上门，要么是用户发现你留着他要求删除的数据。

本文讲的就是怎么给 vibe 项目定一套数据留存策略：哪些数据留多久、留存期怎么定、数据怎么从热存一路走到删除、法务保留怎么冻结、备份里的旧数据怎么办、用户要求删除时怎么删干净，以及上线前必须跑的五组测试。以下示例均为虚构的教学示例，应用、人物与数据均为编造，仅用于说明做法。

一、先划界：留存不是归档，不是备份，也不是“用户留存”

“留存”这个词在产品语境里至少有三个意思，先分开，免得开会的时候各说各话。第一个是用户留存：用户留下来继续用产品，那是增长和召回的范畴，前面《留存与流失召回实战》讲的就是它，跟本文无关。第二个是数据归档：把不常访问的旧数据从热存储挪到便宜的冷存储，前面《数据归档与冷热分离实战》讲的是怎么挪、挪去哪、怎么查回来。第三个才是本文讲的数据留存策略：每类数据应该在系统里存在多久，到期之后怎么处理——删掉、匿名化，还是继续留着。

三者的关系是一条链：留存策略定“留多久”，归档负责“过期之前放哪里更便宜”，备份负责“删错了还能不能找回来”。留存策略是老大，没有它，归档不知道什么该挪，备份不知道什么该过期，删除更不知道从哪下手。反过来，只定留存期、不落地归档和备份策略，留存期也只是一纸空文。

还要跟《账号注销与数据清除实战》划清界：那篇讲的是用户主动注销账号时，一次性把这个人的数据清干净；本文讲的是系统日常的留存规则——哪怕用户永远不注销，日志、工单、埋点这些数据本身也有自己的寿命。注销是“一个人走的时候怎么办”，留存是“所有数据活多久”。注销流程要调用留存策略里的删除能力，但留存策略不等注销流程。

一句话记住：留存策略回答的是“每类数据在我们这里最多活多久、到期后去哪、谁能例外”。凡是不能回答这三个问题的留存文档，都只是写了个标题。

二、留存期怎么定：五把尺子，先量再定

留存期不能拍脑袋，也不能全站统一写“保留 90 天”了事。不同数据的留存期差得非常远：登录日志留 90 天够用，财务发票可能要留 10 年，用户聊天记录可能只能留 2 年。定留存期之前，先拿五把尺子量一遍。

第一把尺子是法律。很多行业对特定数据有最低留存要求：发票、合同、交易记录在很多司法管辖区要求保存 5 到 10 年；医疗、金融数据另有专门规定。反过来，隐私法规也规定了最高留存期：没有正当理由就不能无限期留着个人数据，用完就该删。这两头一夹，留存期就不是“想留多久留多久”，而是一个有上下限的区间。注意：本文不是法律建议，具体数字要以你所在司法管辖区的现行法规和律师意见为准；这里给的是定规则的方法，不是法条。

第二把尺子是合同。企业客户的合同里经常写着数据留存条款：“乙方应保留操作日志不少于 180 天”“项目结束后 30 天内删除全部客户数据”。合同的要求优先于你自己的默认值——签了合同，就要按合同留；合同要求删，就要按时删。接企业客户之前，先把合同里的留存条款摘出来，写进留存清单。

第三把尺子是业务价值。问一句：这份数据在 30 天后还有人看吗？90 天后呢？一年后呢？工单数据在关单后 90 天内经常被翻出来复核，90 天后几乎没人看；埋点数据在发布后两周内最值钱，一个月后只用来看趋势，三个月后基本没人碰。业务价值衰减的速度，就是留存期应该缩短的速度。定期的办法很简单：查一下过去 90 天里，每类数据的访问记录，超过 90 天没人碰的数据，留存期就可以往短了定。

第四把尺子是成本。热存储、冷存储和备份的单价差一个数量级以上。1TB 数据在热存储上放一年和在冷存储上放一年的账单完全不是一个量级。算一笔账：如果某类数据一年访问不到三次，就没有理由让它一直占着热存储；要么归档到冷存储，要么直接删掉。成本这把尺子最适合用来推动清理：把每类数据的月存储成本算出来，贴在留存清单旁边，数字自己会说话。

第五把尺子是风险。数据留得越久，泄露时的损失越大、被要求删除时的工作量越大。特别是个人身份信息、聊天记录、位置数据这些敏感数据，留存期每多一个月，风险就多一个月。敏感数据的默认留存期要往短了定，宁可短了之后按需延长，也不要先定个长的再慢慢缩——缩的时候你会发现，到处都是引用这份数据的代码，根本不敢删。

三、一张可以直接抄的留存清单：四类数据、四种寿命

下面是一张可以直接抄的留存清单模板，数字是示例默认值，照着五把尺子改成你自己的数字。每一行都要写清五件事：数据类别、留存期、到期动作、负责人、例外情况。

数据类别	留存期（示例）	到期动作	备注
业务数据（工单、订单、项目）	关单/完成后 2 年	归档到冷存储，再留 3 年后删除	合同有要求时按合同
操作日志与审计日志	180 天	删除，可保留聚合统计	审计日志另有合规要求时按最长者
埋点与行为数据	90 天原始数据，聚合数据 2 年	原始数据删除，聚合报表保留	聚合时去掉个人标识
聊天记录与用户生成内容	2 年	删除或匿名化	用户要求删除时立即执行
备份快照	30 天滚动	过期快照自动销毁	留存期不得长于线上数据

这张表有三个关键点。第一，留存期要从“业务终点”开始算，而不是从“创建时间”开始算：工单的留存期从关单那天起算，订单的留存期从完成那天起算，聊天记录从最后一条消息起算。用创建时间起算会误删还在进行中的数据——一张开了三年的工单，按创建时间算早就过期了，但它还没关单。第二，原始数据和聚合数据要分开定：埋点原始数据 90 天就够了，但按天聚合的统计报表可以留 2 年，因为聚合数据已经去掉了个人标识，风险低、价值高。第三，备份的留存期不能比线上数据长：线上聊天记录只留 2 年，备份快照却留着 5 年前的数据，等于留存策略白定了。

清单定下来之后要做的第一件事，是把它变成代码里的配置，而不是文档里的文字。每一类数据对应一个留存策略配置：留存天数、到期动作、执行频率。配置要集中放在一个地方，不要散落在十几个定时任务里——散落的配置是留存策略失效最常见的原因：改了一处，忘了另一处，最后没人知道到底哪条规则在生效。

四、数据的一生：热存、温存、冷存、删除，四站走完

数据从产生到消失要经过四站，每一站的存储成本和访问速度都不一样。热存是正在用的数据：放在主数据库里，随时可查，单价最贵。温存是偶尔查的数据：放在便宜一点的存储或者只读副本里，查一次要等几秒。冷存是几乎不查、但还不能删的数据：放在归档存储里，取回要等几分钟到几小时，单价最便宜。删除是终点：数据彻底消失，不可恢复。

走完这四站靠的是定时任务，不是人工。每天凌晨跑一趟清理任务：把超过热存期的数据挪到温存，把超过温存期的数据挪到冷存，把超过留存期的数据删除。每一趟都要记日志：挪了多少条、删了多少条、有没有失败。清理任务本身也要有监控：如果连续三天删除量为零，要么是任务挂了，要么是留存期定得太长，两种情况都要报警。

删除这一步要特别小心，分成两步走：先软删，再硬删。软删是给数据打一个“已删除”标记，用户看不见了，但数据还在数据库里；硬删是真的把数据从磁盘上抹掉。两步之间留一个缓冲期，通常是 7 到 30 天：缓冲期内发现删错了，还能从软删状态恢复；缓冲期一过，硬删执行，数据就真的没了。缓冲期不是留存期，不要把两者混起来：留存期是“数据应该活多久”，缓冲期是“删错了还能反悔多久”。

删除的时候还要处理“引用”：一条工单删了，工单里的附件、评论、操作日志怎么办？一张图片删了，引用它的文章怎么办？规则是：删除要级联，但要分级。主数据删了，从属数据跟着删；被别处引用的共享数据不跟着删，改成匿名化——把用户名换成“已删除用户”、把头像换成默认图，内容本身保留，但再也关联不到具体的人。匿名化不是“把名字打个星号”：只打星号的手机号、邮箱仍然能定位到人，真正的匿名化要把能定位到个人的字段全部去掉或者替换成不可逆的随机值。

五、法务保留：有人喊停的时候，删除键要能锁死

留存策略里最容易漏掉的一环是法务保留（Legal Hold）。正常情况下，数据到期就删；但一旦涉及诉讼、仲裁、监管调查，相关数据就必须立刻停止删除，哪怕已经过了留存期。喊停的人可能是法务、可能是监管机构、也可能是你自己的律师，喊停之后，删除任务必须对这批数据失效，直到保留解除。

法务保留要做到三点。第一，保留是“按范围冻结”，不是“全站停删”：冻结的范围要写清楚，是某个客户的全部数据、某个时间段的操作日志，还是某个项目的全部文件。范围越精确，对正常业务的影响越小。第二，冻结要有审批和记录：谁发起的、为什么冻结、冻结范围是什么、什么时候解除，四件事都要留档。口头说一句“先别删”不算数，系统里必须有一条保留记录。第三，冻结要能穿透备份：线上数据冻结了，备份里的过期快照也不能按原计划销毁，否则等于从备份里把证据删了。

保留解除之后，被冻结的数据要重新进入正常流程：已经过了留存期的，在解除后 30 天内删除；还没过期的，按原留存期继续走。解除也要留档：谁解除的、什么时候解除的、解除之后删了多少数据。法务保留最怕的是“只冻不解”：三年前冻的一批数据，官司早打完了，保留记录还在，数据一直删不掉，最后变成没人敢动的“永久数据”。所以每一条保留记录都要有一个复核日期，到期自动提醒发起人复核：还冻着，还是解除。

六、备份里的旧数据：留存策略最常见的漏洞

老周的第二个教训就出在这里：线上数据删干净了，备份里还躺着三年前的全量快照。备份的本意是“删错了能找回来”，但如果备份永远不过期，它就变成了第二个数据库——一个不受留存策略管辖的数据库。很多团队的留存策略就是这样失效的：线上定得再好，备份一恢复，三年前要求删除的数据又回来了。

修法是给备份也定留存期，而且备份的留存期不得长于线上数据。滚动备份通常留 30 天：每天一个快照，30 天前的自动销毁。30 天这个数字不是随便定的：它要大于删除缓冲期（7 到 30 天），保证删错了还能从备份里找回来；又要小于线上数据的留存期，保证备份里不会躺着线上已经删掉的东西。长期归档备份如果业务确实需要，可以单独留，但要写进留存清单、写清理由、写清到期动作，不能是“一直留着，以防万一”。

用户要求删除个人数据的时候，备份也要处理。正确的做法分两步：第一步，线上数据立即删除或匿名化；第二步，备份里的数据在下一个备份周期内自然过期——也就是 30 天内随着旧快照的销毁而消失。这个做法要写进隐私政策里告诉用户：“您的线上数据已立即删除，备份副本将在 30 天内随备份过期而清除。”不要承诺“备份里的数据也立即删除”，因为那要求你重写所有备份快照，成本极高，而且重写备份本身就可能引入新的风险。诚实地讲清 30 天的窗口，比许一个做不到的“立即”要可信得多。

还有一个细节：恢复演练。每年至少做一次备份恢复演练，恢复出来的数据要按留存策略重新走一遍清理流程，不要把恢复出来的旧数据直接留在生产库里。演练的目的是验证备份能用，不是把三年前的数据复活一遍。

七、用户要求删除时：删干净的四个标准

用户要求删除自己的数据，可能是注销账号、可能是行使被遗忘权、也可能是单纯不想留了。不管原因是什么，删干净有四个标准，缺一个都不算完成。

第一，线上主数据删掉：用户的个人资料、发布内容、聊天记录、订单记录，按留存清单的到期动作执行。第二，关联数据处理掉：评论里的用户名换成“已删除用户”，订单里的收货信息匿名化，操作日志里的个人标识去掉。第三，第三方同步掉：如果数据同步给了统计服务、客服系统、邮件服务商，要通知这些第三方同步删除，或者至少确认合同里写了删除义务。很多团队只删了自己的库，忘了数据还躺在三四个第三方服务里。第四，备份按窗口过期：按上一节的做法，30 天内随备份过期而清除，并把这一点告诉用户。

删除请求本身也要有流程：收到请求后先确认身份——不能别人发一封邮件，你就把别人的数据删了；确认之后给一个明确的时间承诺，比如“15 天内完成删除”；完成后给用户一封确认邮件，写清删了哪些类别的数据、备份副本何时清除。整个过程要留档：谁请求的、什么时候请求的、什么时候完成的、删了哪些类别。留档不是为了留着用户的数据，而是为了证明你确实删了——万一以后有人问起来，你拿得出记录。

还有一个容易忽略的点：删除不是“把账号变回未注册状态”。用户注销之后，他的用户名能不能被别人重新注册？他的公开内容是跟着删掉，还是匿名化后保留？这两个问题要在留存策略里提前定好，不要等用户问了才临时决定。一般的做法是：用户名在注销后 90 天内保留不放出，防止有人冒充；公开内容匿名化后保留，因为删掉会影响其他用户的阅读体验——但这一点必须在隐私政策里提前讲清楚。

八、落地 SOP：从一份清单到每天自动跑

留存策略最后要落到一张可以执行的清单上。下面是建议的上线步骤，按顺序做，不要跳步。

第一步，盘点：列出系统里所有的表和存储桶，给每一类数据定一个负责人。盘点的时候一定会发现“不知道是谁建的表”“不知道这个字段是干什么的”——先记下来，标成“待确认”，不要猜。第二步，定留存期：按第二节的五把尺子，给每一类数据填留存期和到期动作，写进留存清单。第三步，写配置：把留存清单变成代码里的配置，清理任务按配置执行。第四步，上监控：清理任务每天跑完之后，记录删除量、失败量、剩余量，连续三天异常就报警。第五步，写隐私政策：把留存期和删除流程写进隐私政策，告诉用户每类数据留多久、怎么要求删除。

监控指标建议盯住四个数字：每天删除的数据量（突然为零就是任务挂了）、超过留存期还没删的数据量（积压越来越多就是任务跑不完）、备份快照的年龄（最老的快照超过 30 天就是过期策略失效）、待处理的删除请求数（超过承诺时间没处理完就是流程出了问题）。这四个数字每周看一次，写进周报，不用天天盯，但不能没人看。

留存策略不是定一次就完事的文档，每年至少复核一次：法规变了没有、合同多了哪些新要求、业务上哪些数据已经没人看了、成本上有没有哪类数据贵得离谱。复核的时候顺便检查法务保留记录：有没有早该解除还没解除的冻结。复核的结果要留档：改了哪些留存期、为什么改、谁批准的。

九、上线前跑五组测试，再谈“做完了”

组别	测什么	通过标准
清单完整	对着数据库逐表核对留存清单	每张表、每个存储桶都有留存期和到期动作，没有“待确认”超过 30 天
删除执行	造一批过期测试数据，跑清理任务	过期数据被删除，未过期数据 untouched；软删缓冲期内可恢复，缓冲期后硬删查不到
级联与匿名化	删一个测试用户，查所有关联表	从属数据跟着删，共享数据匿名化，日志里查不到该用户的个人标识
备份过期	查最老的备份快照年龄，模拟一次恢复	最老快照不超过 30 天；恢复出来的旧数据按策略重新清理，不留在生产库
删除请求	走一遍完整的用户删除请求流程	身份确认、15 天内完成、确认邮件发出、全程留档；第三方同步删除已通知

最后留一张验收清单：留存清单覆盖全部数据表和存储桶；留存期按五把尺子定过，有据可查；清理任务每天自动跑，有监控和报警；软删加硬删两步走，缓冲期已验证；法务保留能按范围冻结、能到期复核、能解除；备份留存期不长于线上数据，用户删除的备份窗口已写进隐私政策；删除请求流程跑通过，全程留档。七条全打勾，这套留存策略才算做完。数据留存做得好，用户看不见、法务挑不出毛病、账单也不会突然涨三倍——最好的留存策略，就是让人感觉不到它存在的那种。