你有没有想过一个问题：平台上那些"跑着但没人用"的虚拟机、"创建了但从没挂载"的云硬盘、"拍了但早过期"的快照——它们加起来，占了你多少存储空间？
我们在日常巡检中发现，一个中等规模的私有云环境里，通常有15%-30%的资源属于"僵尸状态"。它们不报错、不告警、不影响业务，但它们实实在在地占用着你的存储容量和资源配额。
等到哪天你真正需要空间的时候，才发现配额早就被这些"幽灵"吃完了。
Q1：哪些资源最容易变成"僵尸"？怎么把它们找出来？
超过90天没人碰的虚拟机。
它们还在"运行中"，但已经三个月没有任何登录、重启、配置变更。在平台的"资源使用统计"中，如果一台虚拟机CPU使用率持续低于2%而且没有网络流量，基本就是僵尸了。
创建了但从没挂载的云硬盘。
可能是当初测试时创建的，也可能是某次操作后卸载下来忘了清理。在存储管理中筛选状态为"可用"（未挂载）且创建时间超过30天的云盘，就能找到它们。
堆积的过期快照。
快照是好东西，但不能无限存。特别是某些存储类型的快照是链式结构，越积越多不光占空间，还拖慢整体读写性能。如果你从没设置过"快照自动清理策略"，快照很可能已经积了几十甚至上百个。
回收站里的资源。
很多人不知道：你删除虚拟机或云盘后，它们会先进入"回收站"，在保留期内仍然占用存储空间。如果回收站保留时间设得很长（比如30天），里面可能积压了大量已经确认不需要的资源。
管理节点上的日志文件。
系统日志、数据库日志如果没有配置自动轮转清理，日积月累可能占据几十GB。我们见过管理节点系统盘被日志撑满的案例——系统盘满了，整个平台都可能出问题。
Q2：清理的时候，怎么避免误删？
最怕的就是："看着没用"但其实在默默干活。
先关机观察，不要直接删除。
把疑似僵尸的虚拟机先关机，观察7-14天。如果这期间没人来喊"我的服务怎么挂了"，基本确认是可以清理的。直接删除风险太大——万一它是个定时任务服务、日志收集节点、或者内部DNS，删了就是一场事故。
批量清理快照时要分批做。
一次性删除大量快照会导致存储后台大量数据整理操作，可能短时间内拖慢整体存储性能。建议每次删10个以内，选业务低峰期操作，删完观察一下存储延迟再继续。
清空回收站前再确认一次。
回收站是"误删"后的最后安全网。清空之前，快速过一遍最近一周删除的资源列表，确认没有"手滑删掉"需要恢复的。
日志不要直接rm删除。
正在被系统写入的日志文件如果直接删除，空间不会立即释放（文件句柄还在），而且可能导致对应的服务异常。正确的做法是配置日志轮转策略让系统自动管理，或者先"截断"文件（清空内容但保留文件），再等日志系统自动重建。
Q3：怎么建立长效机制，而不是每次都靠人工"大扫除"？
靠人记忆去定期清理，迟早会忘。好的做法是把清理动作"自动化"或"制度化"：
配置快照自动清理策略。
平台支持"定时快照+保留策略"的组合——比如每天自动快照，保留最近5个，超出的自动删除。配好之后就不用操心了。
调整回收站保留时间。
默认可能是30天。如果你的存储空间本来就紧张，可以考虑调整为7天——绝大多数"我删错了"都会在几天内发现。
每月做一次资源审查。
把它作为常规运维流程的一部分。内容很简单：导出资源统计报表，看看有多少90天未操作的虚拟机、多少未挂载的云盘、快照总量是否在合理范围内。把这些数据纳入月度运维报告。
确保日志轮转策略在运行。
管理节点的系统日志、数据库日志都应该配置了自动轮转和过期清理。检查一下配置是否存在、是否在正常工作。如果没配置，花10分钟配一下，能省掉未来很多麻烦。
设置存储容量告警。
这是最后一道防线——即使前面的策略都没执行好，至少在容量到达危险水位时能收到通知。建议阈值设在80%。
自查清单：5件事帮你摸清"家底"
导出资源统计报表，看看有多少90天未操作的虚拟机和未挂载的云盘
检查快照总量——是否有虚拟机快照超过5个？是否配置了自动清理策略？
看一眼回收站设置：保留时间是多少天？里面是否有大量积压？
登录管理节点看磁盘使用率——/var/log 目录是否超过10GB？日志轮转是否正常？
存储容量告警是否已配置？通知渠道是否畅通？
这些情况建议联系技术支持
需要批量清理大量快照（超过100个），想确认对业务的影响范围
存储已经超过85%，需要帮你制定紧急清理的优先级
快照链过长导致读写性能下降，需要评估重建方案
资源删除后空间没有正常释放，怀疑平台回收机制异常
管理节点磁盘满导致服务异常，需要紧急恢复
想要定制化的自动清理脚本或运维巡检方案
