云上资源增长通常比预期快。项目刚开始时可能只有几台服务器和一个存储桶，半年后就可能变成几十个 Bucket、上百块云盘，账单里还夹着越来越多的快照和历史日志。做阿里云空间管理，目的很简单：让这些存储资源看得见、管得住，成本也能算清楚。
先分清楚都有哪些空间
阿里云上的存储大致可以分成几类：对象存储 OSS 的 Bucket 和对象，ECS 上的云盘与快照，文件存储 NAS 的文件系统，还有数据库和日志服务占用的空间。每一类的计费方式和治理手段都不一样。如果混在一起看，最大的那一笔往往最容易被忽略。建议先按类型拉一张清单，分别记录数量、容量和每月费用，再决定先处理哪一块。
先打标签，再谈权限
第一步是给资源统一打标签，比如 project、env、owner、cost-center。有了标签，账单可以按项目或环境拆开看，无人认领的资源也能很快筛出来。资源组则适合做权限隔离，让每个团队只看得到、也只能操作自己负责的空间。
标签规则最好在项目立项时就定下来，写进团队的基础设施规范。事后补标签很费事，而且通常补不完整。新建资源时如果没有 owner 标签，就应该在创建流程里直接拦住。
OSS 生命周期规则怎么配
对象存储通常是空间膨胀最快的地方。日志、备份、临时导出文件往往只在短时间内有用，却一直占着标准存储。OSS 的生命周期规则可以按前缀或标签设置自动转换和过期，比如：
- logs/ 前缀下的对象 30 天后转为低频访问存储，180 天后删除；
- tmp/ 前缀下的对象 7 天后自动过期；
- 历史归档数据转为归档存储，需要时再解冻读取。
低频和归档存储都有最短保存期，取回也要额外收费。如果某个前缀的数据其实经常被读取，转成低频存储后反而更贵。所以规则上线前，先用存储量分析看一下各前缀的访问频率，再决定转换的时间点。规则配完后，过一两个计费周期回头看账单，确认没有意外的取回费用。
云盘和快照别让它们自己长
ECS 实例释放以后，云盘仍然可能保留着，快照也会因为自动快照策略不断累积。建议每月检查一次状态为“未挂载”的云盘，逐一确认负责人。快照的保留策略也要和实际恢复需求对一下：生产数据需要的保留周期，和测试环境通常不一样。
删除之前有一件事必须确认：数据是否已经备份，或者已经不再需要。云盘和快照删除后通常无法恢复，这一步没有撤销的余地，最好和业务方一起过一遍清单再动手。
用配额和告警提前拦住
空间管理不能只靠事后清理，还要在前面设防。可以用云监控给 OSS 存储量、流量，以及 ECS 磁盘使用率设置阈值告警，阈值留出足够的反应时间。同时结合资源管理的配额能力，限制单个项目能创建的资源数量。多账号场景下，资源目录可以统一设置管控策略，避免某个子账号随手开通大规格资源。
一个实际案例
某内容平台上线两年后，账单里的存储类费用一直在涨。团队梳理后发现三个问题：测试环境遗留了大量未挂载的云盘；OSS 里的应用日志从没设置过期规则，累计超过 40TB；自动快照策略对所有磁盘统一执行，保留周期长达 90 天。
处理方式分三步走。第一，用标签筛出无负责人的资源，经确认后分批释放，不一次全删。第二，给日志前缀配置生命周期规则，超过 90 天的日志转入归档。第三，快照策略按磁盘类型分级，生产库保留 30 天，测试环境保留 7 天。三个月后，存储相关费用下降了约三成。更重要的是，资源巡检变成了固定流程，不再依赖某个人的记忆。
几个容易踩的坑
第一个坑是觉得存储单价低，就不必管。单价低的资源一旦无限增长，总量依然很可观。第二个坑是只靠人工巡检，没有自动化规则，总会有遗漏。第三个坑是清理时只看容量，不看数据用途。删除前应该和业务方确认，必要的备份也要留好。
收尾
把标签、生命周期、快照策略和监控告警串成一套能持续运行的机制，阿里云空间管理就算立住了。先把资源看清楚，再用规则代替人工记忆，成本和风险都会变得可预期。
