经常面临CMDB数据变更滞后于数据源的数据变更，如何变被动数据治理为主动数据治理？

从时间结构上看，CMDB和其他活动的因果关系分为两种：
一种是先“变更”再更新CMDB，变更活动是“因”，CMDB是果。这种情况CMDB比较被动，你要么要(gui)求(qiu)人家改你的CMDB，要么想办法通过数据发现自动捕捉人家的变化。
另一种是先更新CMDB，再实施变更。CMDB是因，变更活动是“果”。这种方法还有个好听的叫法“配置驱动”，是一种配置中心化的软件定义。从流程设计上，让CMDB成为下游环节的依赖前提。从系统架构关系上，让CMDB成为运维系统的配置中心。需要提醒的是，这种方式并不一定要用户在CMDB自身门户中操作，完全可以在运维场景中，用户直接在运维工具中，通过API间接维护和消费CMDB。用户甚至感觉不到CMDB的存在。
第二种从策略上说肯定是最优的，变被动为主动。

我们实现比较简单，所有的执行流程，如果涉及到配置对象的变动，最后执行流程得有一个动作，更新配置对象到CMDB中；
如交付10台虚拟机，这10台虚拟机完成初始化后，直接更新到CMDB对于的业务和模块下面，强调流程的闭环。