结论先行：私有云的难点不只在建。资源是逐年加上去的，台账却往往没跟着长，于是出现了几种典型的尴尬：资源归属说不清、闲置的没人敢动、真要退场时发现数据还没搬、策略还没摘。可行的做法是把三件事做成常态：资源有台账并落到责任人、退役有判据与审批、退场前先安排数据与策略的承接。
为什么"建的时候清楚、用起来就乱"
私有云项目立项时通常有一份完整的资源清单，因为要采购、要验收。麻烦出现在之后：新业务上线加一批虚拟机、临时项目借一批资源、试点环境搭完忘了关。这些动作单独看都很合理，累积两三年，资源池的构成就和当初那份清单对不上了。
更麻烦的是归属。资源挂在某个管理员账号下、以某个已离职同事的名字命名、或者只留了 IP 没留业务信息——一旦归属不清，就没人有动力也没有权限去处理它。资源闲置而不退，最后体现为两点：采购预算被提前消耗，安全上则多出一批没人维护、可能长期不更新补丁的影子资产。
一件事：台账，而且台账要能落到人
台账的粒度不必一开始就做到很细，但要满足三个可检索的条件：
- 能按业务系统查到资源。每个资源实例都要能回答"它属于哪个业务系统"，而不是只给一个 IP 或主机名。
- 能追到一个责任人。每条记录都要有一个当前有效的对接人和对接部门。出现无主条目的那一刻，基本可以判定台账已经和实际情况脱节。
- 能和资产与配置管理的口径对上。台账如果自成一套，盘点时必然要人工核对两遍。可行的做法是让云平台侧的接口与配置管理、资产台账打通，把资源归属、业务等级这些字段做成同步关系，而不是各自维护。
第二件事：退役要有判据，也要有审批
没有判据，"要不要退"就变成主观判断，谁都怕背责任，结果就是都不退。建议把判据提前写清楚，让判断变成对照条件，而不是讨论。常用的几条：
- 闲置。连续若干周期没有有效负载或访问记录。判据要能排除周期性业务，避免把每季度跑一次的批处理当成闲置。
- 性能或容量已不满足。资源规格与业务需求长期不匹配，继续占用只会拖累整体水位。
- 安全基线不达标。长期无法完成补丁更新、无法纳入统一策略管控，属于只能退役而不能继续承载的情况。
- 架构替换已完成。业务已经迁到新环境并稳定运行一段时间，旧实例完成了并行观察期。
判据之外，审批环节同样重要。退役动作建议纳入统一的变更流程与留痕机制：谁提出、依据什么判据、谁批准、什么时候执行，都要能查到。这样做的价值不只是合规，更在于让退役变成一件"有依据所以敢做"的常规动作。
第三件事：退场前先把承接安排掉
这一条最容易被跳过，也最容易出事故。资源退役不是关机，动作顺序大致是：
| 顺序 | 动作 | 常见遗漏 |
|---|---|---|
| 1 | 确认数据是否还需要保留，需要保留的先备份或迁移并验证可恢复 | 只做了备份，没有验证能不能恢复 |
| 2 | 梳理该资源上的访问关系与权限，逐条确认承接方或摘除 | 权限留在原处，退役后变成指向空对象的规则 |
| 3 | 确认上游依赖与调用方已切换，并保留一段并行观察期 | 直接下线，调用方在业务高峰才报错 |
| 4 | 监控、告警、备份任务、巡检项同步下线或转移 | 告警还在跑，持续产生无人认领的噪音 |
| 5 | 资源与账号回收，台账状态更新为已退役并归档 | 只回收了机器，账号与授权还在 |
存量设备的去向要提前定
私有云扩容或替换时，被换下来的设备通常有三种去向：继续承载非核心业务、转为备份或测试用途、正式退役。这件事要在扩容方案的设计阶段就写清楚，不要等到设备闲置了再讨论。把它和上文的台账、判据接起来，资源的进出就都有据可依。
奇摩在数据中心基础架构项目中，通常会把资源台账口径、退役判据与承接动作和扩容方案一起给出，避免出现"设备买了、旧设备没人管"的情况。深耕 IT 基础架构 25 年，这类存量治理的活我们在金融、能源、政务客户的机房里做过不少。
私有云的资源治理涉及平台、资产、运维三条线，欢迎预约咨询，奇摩可以把台账口径、退役判据与承接动作一起过一遍。