容量规划需按业务生命周期管理数据价值：热、温、冷数据分层存储，归档要分层+打标+可追溯，清理须经扫描、评估、灰度、确认四步验证，并纳入SRE体系度量。
容量规划不能只盯着“还能撑几天”，得把数据放在业务生命周期里看——哪些数据正被高频使用，哪些已进入归档态，哪些其实早该退出舞台。归档与清理不是技术操作，而是对业务阶段的响应。
按业务阶段定义数据价值周期
同一份数据，在不同阶段价值完全不同。比如制药企业的靶点筛选数据：
- 项目进行中：结构库、特征向量、模型权重是热数据，需全闪存储+高IO保障
- 项目结题后3个月内：用于复盘、审计、申报，属温数据，可转入混闪或对象存储
- 结题满18个月且无引用记录：若非法规强制保留（如GCP要求），即为冷数据，应标记为可清理候选
关键不是“存了多久”，而是“是否还在支撑当前业务动作”。建议在元数据中标注project_phase、last_used_by_task、retention_policy_ref三类字段，作为归档决策依据。
归档不是搬家，是分层+打标+可追溯
单纯把旧表导出到另一个库，不解决根本问题。真正有效的归档要满足三个条件：
- 分层明确：活跃库（OLTP）只保留最近12个月交易数据；历史库（OLAP）存放聚合后的年度快照；归档库（WORM/对象存储）仅存原始凭证级文件，启用不可删写保护
- 标签化管理：用对象标签（如archive:2025-Q3、compliance:gdpr-7y）替代目录命名，便于批量策略匹配
- 访问链路保留：归档后仍需支持按主键/单据号查询，前端不感知存储位置变化。可通过视图路由或代理层实现透明访问
清理必须带验证闭环，不能只删不验
清理风险不在“删多少”，而在“删错谁”。推荐执行四步验证机制：
- 前置扫描：用存储空间清单（Inventory）导出待清理范围内的最后访问时间、关联任务ID、下游依赖表
- 影响评估：检查是否有BI报表、定时任务、API接口仍在引用这批数据
- 灰度执行：先对1%样本数据执行软删除（加is_deleted=1标记），观察72小时业务日志与错误率
- 硬删确认：确认无异常后，再触发物理清理，并自动归档操作日志至独立审计库
把归档清理变成可度量、可调度的运维能力
避免靠人工盯表、临时脚本清理。应纳入SRE可靠性体系：
- 定义SLI：如“归档任务按时完成率 ≥99.5%”、“冷数据误删率为0”
- 配置SLO：每月3日前完成上月温数据归档；每季度末前完成超期冷数据清理审计
- 嵌入自动化：通过CloudLens或自建采集器监控各层存储占比，当归档层利用率＞75%时自动触发扩容或清理策略重评估
不复杂但容易忽略：归档清理的本质，是让存储资源始终匹配业务当下最真实的需要，而不是堆砌过去所有“可能有用”的数据。
