台账上的机器和真在跑的机器，差在哪

结论先行：配置库里放着的通常只有一份清单，而实际上应该有两份：一份是「规划预期资源」，来自申请单与设计方案；一份是「实际运行资源」，来自真实观测。两份之间的差异有三类：规划里有而实际没跑起来的、实际在跑而台账上没有的、以及规格悄悄变了的。任何一家跑过几年的环境，差异都不可能为零，问题不在于消灭差异，而在于有没有人定期把差异当成一件要处理的事。

本文只谈配置库中「预期与实际」两份清单的差异治理，不谈终端侧该采哪些字段，也不谈工单与报修流程怎么跑。

为什么两份清单一定会分开

申请的时候，人们描述的是想要的资源：几核、多少内存、什么规格、给哪套业务用。这份描述进了申请单，也进了配置库。看起来台账已经建好了。

但资源从申请到真正运行，中间还有若干步不由申请流程控制：有人克隆了一台做测试、有人扩容时直接改了规格没走单、有人迁走了业务但虚机没关、有人删了实例但台账没销。每一步都很小，累积几年之后，台账就成了一份历史文档。

关键的一点是：观测数据一直都在，只是从未被拿来跟台账对过。监测系统知道当下有哪台实例在跑、跑着什么进程、连着什么服务；台账记的是当初谁申请的。两者从来没有放在一起看过。

三类差异，处置方式完全不同

把差异分类比统计总数有用得多，因为三类的成因与处理动作不一样。

三类的风险不等。僵尸实例主要影响成本与盘点口径——它会让人误以为资源还有余量，也会让许可证与维保数量算不准。规格漂移影响的是容量判断，做了扩容却按旧数据算，扩容决定就是错的。

缺失资产最危险。它不在纳管范围内，意味着不打补丁、不在监测里、不在巡检清单上，也不在任何一次隐患排查的覆盖范围内。它平时安静，出事的时候所有人都是头一次听说。

为什么靠人工盘点治不了

多数单位解决这件事的办法是年度盘点：发一张表，各部门填，收回来汇总。这个方法有一个结构性缺陷——它采集的仍然是「人们认为的」，而不是「实际在跑的」。

填表的人会漏掉自己不记得的那几台，也会把已经下线的写上去。填完之后得到的是第二份「规划预期」，用来跟原来那份对比，只能看出填表口径的差异。

可行的做法是让其中一份数据来自自动观测：从网络的连接关系、从监测系统的实例清单、从虚拟化平台与容器平台的资源列表里取。三处交叉之后得到的清单不需要任何人回忆，它反映的是当下真实在跑的东西。

有了这份清单，盘点就变成一个机械的比对动作：两边做差集，人工只需要确认差异那几十条，而不是重新盘几千条。

从拓扑反推是最省力的入口

如果观测数据还不完整，有一个成本较低的起点：服务调用关系与网络连接关系。

任何在跑的业务都会有连接。监测系统里的调用拓扑、网络侧的连接记录，能勾出一张「谁在跟谁说话」的图。把这张图和台账比，两类差异会直接显现：台账里没有、但持续出现在拓扑里的节点（缺失资产），以及台账里有、但半年没有任何连接的节点（疑似僵尸）。

这个方法的局限要说清楚：完全隔离、不产生任何连接的设备和实例是看不出来的。但对于数据中心里多数业务系统，连接关系是足够稳定的判据。

差异治理要落在流程上，不是落在表上

比出差集只是开始。如果差异清单出来了，但没有人对它负责，三个月后它会重新长回去，而且这次会长得更快，因为大家知道这张表出来也没人动。

三条可落地的做法。

其一，把「回填」写进变更流程。扩容、重装、克隆、迁移这四类动作完成后，回填台账成为完成条件之一，而不是可选项。这条最难推，但它决定了差异会不会持续产生。

其二，缺失资产先管风险再补手续。发现一台不在纳管的实例，动作顺序应该是：先确认它有没有打补丁、有没有在监测里、有没有暴露在可访问的位置，然后才补登记。反过来做，等于让它在「已登记」的状态下继续裸奔。

其三，僵尸实例给一个确认期，别直接删。台账里有、实际无痕迹的实例，先标记并通知归属人，给一个确认期（比如两周），期内无人认领再销账。直接删除的风险是删掉了某套没人知道还在依赖的东西。

一个可以放进月报的数字

差异治理需要一个能被追踪的指标，否则很难证明它在改善。

可行的数字有三个，选一个固定上报即可：缺失资产数量（越少越好）、僵尸实例占比（相对台账总数）、以及规格漂移条目数。三者中建议把缺失资产数量放在前面，因为它同时代表风险敞口。

不建议用「一致率」这类百分比作为主指标。它看起来直观，但分母是台账总数，销账动作本身就能让数字变好，与风险无关。

落地清单

• 在配置库里明确区分「规划预期」与「实际运行」两份清单。
• 观测侧至少接两处数据：虚拟化或容器平台资源列表、监测系统的实例清单。
• 从服务调用拓扑与网络连接反推，作为缺失资产与僵尸实例的初筛入口。
• 三类差异分开处置：僵尸确认后销账、缺失先管风险再补登记、漂移以实际更新台账。
• 把回填写进扩容、重装、克隆、迁移四类变更的完成条件。
• 僵尸实例先标记并给确认期，不直接删除。
• 月报固定上报一个数字，建议用缺失资产数量。

边界与前提

三点说明。其一，文中所述的两份清单与三类差异属配置管理的一般性梳理，具体字段与流程须结合现有台账结构与管理要求调整。其二，观测数据的完整性取决于所接平台的能力与纳管范围，落地前应以实际数据验证为准。其三，销账与资产处置涉及财务与审计口径，须按内部制度执行，本文不构成对资产核销的建议。

深圳市奇摩计算机有限公司是一家 IT 解决方案服务商，在监测与运维平台项目里会把「预期与实际」的比对做成一项例行动作，而不是一次性的盘点。预约咨询，可以先从现有台账与监测清单的一次差集开始。