只有采集到字段级，替换才算真正完成

替换配置管理工具的讨论，通常从许可报价开始，以"新旧功能对照表"结束。真正决定项目成败的部分在这个区间之外：新环境里能采到哪些属性、关系能不能自动推出来、旧数据搬过来之后还能不能信。装完、跑起来、界面能打开，都只是起点。

一、替换的开销结构：许可只是最小的一项

把支出拆成五项，会看得更清楚。第一项是许可与订阅，金额明确、可按规模询价，也是少数可以直接比价的一项。第二项是实施与模型定制，模型一旦偏离标准结构，后续每次升级都要重做改造。第三项是迁移与清洗，工作量取决于旧数据有多脏，而不是有多少条记录。第四项是双栈并行期的重复投入。第五项是长期治理人力。

在新建项目里，第一项往往占主要位置；在替换项目里，后四项的占比会上升。原因是替换同时做三件事：换载体、清历史、建规范，而第二件与第三件几乎没有外部报价可参照。

因此用"许可价差"作为决策依据是不成立的。可行的比较方法是把五项并列，按同等纳管范围逐项估算，再看总和的差；如果只比第一项，会系统性地低估实施与迁移，也会高估替换的收益。

二、装得上为什么采不到：从进程存活到属性缺失

第一层原因是验证口径太浅。安装包能装上、进程能起来、日志没有报错，这三项通过之后，很多人认为适配完成。但配置采集要的不是进程存活，而是属性值：处理器与内存用量、连接数、会话数、缓存命中、队列长度、磁盘与文件系统的容量信息。

第二层原因在取值路径。这些属性来自系统视图、命令输出、性能接口三类来源，而这三类在异构环境里的形态都不统一。系统视图的字段名与表结构不同，命令输出的分隔符与字段顺序不同，性能接口的调用方式与返回结构不同。启动兼容只解决了"进程能跑"，属性采集解决的是"值能取到、能解析、能对上名称"。

两层叠加后的结果是属性完整度不足。表面上每个对象都有记录，实际上大量字段为空或取到占位值。后续所有依赖属性的判断都会失准：容量分析用不到真实用量，影响分析拿不到真实关系，稽核规则报不出有效差异。

判断方法很直接：随机抽一批对象，把关键属性的非空率与人工核对结果做对比。这个动作在演示环境里做不出来，因为演示环境通常只覆盖最容易的那类系统。

三、采集侧的关键实现：通道、模板与字段映射

采集能力能不能扩展，取决于采集层是否与模型层解耦。解耦的做法是把"取什么"与"从哪取"分开：模型层定义属性名与类型，采集层用模板描述取值方式，两者通过映射绑定。

一张采集模板要写清五件事：用哪种取值通道（远程执行、只读接口还是日志解析）、针对哪类对象、每条属性从哪个命令或哪个系统视图中取、如何从输出里解析出字段、取不到时如何降级。这五项里，通道与解析必须分开写：命令换了只改通道，输出格式变了只改解析，模型层的属性名与类型不动。模板还要能热更新，新增一类组件的采集不必等版本发布。

三处细节决定这套模板能不能长期用。其一，取不到就留空并打标记，不要写默认值——默认值会让缺失看起来像正常，稽核永远发现不了。其二，字段要带类型与单位，否则同一属性在不同实现里的两种单位会被当成两个值参与比较。其三，模板变更要有版本与生效范围，老对象按旧模板采、新对象按新模板采，避免一次性全量切换引发大面积空值。

插件化的意义也在这里：采集能力随被管对象的种类增长，而对象种类只增不减。把采集写成硬编码，等于把未来的扩展成本锁死。

四、配置模型的两层：属性与关系的推导机制

配置数据分为属性与关系两层，前者描述"它是什么"，后者描述"它连着什么"。属性层靠采集，关系层靠三种来源推导。

第一种是显式声明，例如虚拟化平台给出的虚拟机与宿主归属、负载均衡给出的后端成员列表。这类关系最可靠，但覆盖率受限于接口暴露程度。第二种是连接与端口表，从网络连接反推调用关系；它能覆盖没有接口的系统，但区分不了主动与被动、长连接与瞬时连接。第三种是日志与链路中的上下游信息，准确度较高，但要求有统一的标识与足够的采样。

三种来源得出的关系会有冲突，需要置信度与优先级：显式声明优先，其次端口与链路，最后是配置文本解析。冲突时要保留两个版本并标记待确认，直接覆盖会让错误的关系变成"事实"。

关系层的时效性比属性层更脆弱。实例重建、迁移、扩缩容都会让关系在短时间内失效；如果关系只在夜间批量更新，白天的影响分析就会基于过期拓扑。这是配置数据"看起来有、实际不对"的主要来源之一。

五、迁移会把旧数据的隐患一起搬过去

迁移最容易犯的错是把它当成搬运。旧系统里的重复实例、指向已下线设备的关系、拼写不一致的命名、手工补录的占位对象，如果原样搬进新系统，新系统从第一天起就继承了旧系统的信任问题。

更隐蔽的是并行期的分裂。新旧两套同时在采，同一台机器在两处的属性更新时间不同、关系推导规则不同，比对时差异项会被当成"迁移未完成"处理，而真实原因可能是两套逻辑本来就不一致。

可行的处理顺序是反过来的：先在新系统重建模型与命名规范，抽样清洗旧数据，选少量业务域试迁并重点核对关系完整度，再分批迁移。属性层的问题不必在迁移阶段全部解决，交给新系统的稽核规则持续纠正，比一次性清洗更现实。

迁移完成的判定标准也要换。不是"迁过来多少条记录"，而是"关系完整度是否达到约定的口径"与"关键属性的非空率是否可核对"。前者决定影响分析能不能用，后者决定容量与合规报表能不能出。

六、数据质量的验证口径：核对项与趋势

质量不能靠抽查一次下结论，要靠可重复的口径。可用的核对项有四类：属性完整性（关键字段是否为空）、关联完整性（对象是否挂在正确的关系上）、孤岛对象（有记录但没有关系、或长期无更新的对象）、命名规范性（是否符合约定，是否存在同物多名）。

四项之外还有两个指标更能反映运营状态：自动维护比例，即有多少对象由采集自动更新而非人工录入；质量分趋势，即上述核对项随时间的变化方向。前者决定数据会不会腐化，后者决定治理是否在起作用。

抽查方法也要固定下来：每次抽同一类对象、同一批关键属性，与人工核对结果比对，记录偏差。抽查的意义不在于得出一个精确的分数，而在于发现偏差的分布——是集中在某类操作系统，还是集中在某个采集通道，指向的整改动作完全不同。

七、切换顺序：先定规范，再对关系，最后补属性

切换顺序由依赖关系决定。模型与命名规范必须先定，否则采集到的数据无处安放；关系必须在属性之前，因为属性缺失只影响分析精度，关系错误会影响影响面判断与变更决策。

落地顺序可以这样排：先定模型与命名规范并冻结一版；再抽样清洗、试迁一个业务域、核对关系；然后按业务域分批迁移，每批结束做一次双轨比对；最后撤掉旧系统的写入权限，只保留只读查询一段时间。

时点选择同样重要。太早，目标环境的软件栈还没定型，模型要反复改；太晚，各业务域已经各自建了临时台账，收回来要跨团队协调。相对合适的窗口是基础设施替换完成、业务系统尚未大批量迁移的间隔期。

回滚点要设在每一批迁移之前，并且实际演练过。只在文档里写"支持回滚"与真的能回滚，是两件事。

八、三条路线的取舍：能力边界由架构决定

三条路线的差别不在功能清单，而在架构留给使用者的空间。成熟方案把适配与治理做进产品，换来的是响应速度；开源自研把控制权全部交出，换来的是人力投入；保留外部平台加隔离层解决的是合规过渡问题，不是替代问题。

选择开源自研时，最常被低估的是治理机制的建设成本：稽核规则、待办分派、修正回写，这些都要自己长出来，而且需要长期有人维护。团队没有稳定投入的情况下，三年总支出往往不低于商业方案。

九、什么条件下自研划算，什么条件下不划算

自研划算的条件比较具体：对象种类稳定且数量可控、团队有持续投入的能力、配置模型与业务强相关且外部方案难以覆盖、治理要求可以由内部流程吸收。不划算的条件同样具体：对象种类快速增加、团队以项目制临时组建、需要对外报送或接受外部审计、缺少长期维护的人手。

三条路线的共同底线是：替换之后，采集、治理、消费三个环节要在新平台上重新转起来。替换改变的是数据的载体，不改变配置数据需要持续运营这件事；把替换当成一次交付而不是一段运营，是这类项目最常见的失败方式。