一个传统系统，如果想实现运维自动化，最好从哪里先开始？http://www.talkwithtrend.com/Question/417181有多位专家分析过这个问题。

CMDB的管理要求当然可以纳入IT标准和制度里。比如CMDB和其他运维平台的集成关系，那些公共配置信息必须以CMDB为主配置库，中心化管理。但IT标准化不是神丹妙药，标准不是几个专家拍个脑袋就能搞定的。标准是一种共识，而且这种共识往往是从整体和长远视角，和执行单位存在“错配”...

CMDB是IT数据中心的软资产，可以看成是资本，新技术重塑的业务肯定要从CMDB的环境中分离出去。就像银行会计核心系统，会计准则是不会变，变的是周边系统和资产放哪儿更合适？一个是技术主导，一个是信息资产。就看覆盖面到什么程度，就像云环境下的虚拟化、Docker使用，总还有为数不少的...

行业里有厂商已经在实践了。可参见 http://www.talkwithtrend.com/Question/426377。另外有篇文章可参考：https://blog.csdn.net/kwame211/article/details/78410512

CMDB的数据存储结构和你的业务需求规划有紧密的关系；我们采用的MongoDB这种文档型数据库，比较灵活。

从时间结构上看，CMDB和其他活动的因果关系分为两种：一种是先“变更”再更新CMDB，变更活动是“因”，CMDB是果。这种情况CMDB比较被动，你要么要(gui)求(qiu)人家改你的CMDB，要么想办法通过数据发现自动捕捉人家的变化。另一种是先更新CMDB，再实施变更。CMDB是因，变更活动是“果”。...

cmdb和云平台是 数据消费者和数据保存者关系云平台需要纳入cmdb管理cmdb从云平台获取信息或者云平台推送信息,避免多个接口接入vcenter导致接口混乱具体业务实现看具体需求

如果您指的是CMDB数据治理，那问题和 http://www.talkwithtrend.com/Question/426353 比较类似。如果是整个公司IT数据治理，话题就大了。DAMA(国际数据管理协会)数据管理职能框架内容非常丰富，但具体落地时您提到的这种情况，根本冲突，个人觉得从“成本-收益”角度来分析。首先，...

我们公司的自动发现策略，是先进入调和库，要么是用作初始化，要么为配置项负责人提示差异，最后人工决定是否要修改或删除。因为自动发现总有各类意外或不准确，还有可能同一个mysql实例可能通过多个自动发现渠道捕捉到，如果直接进CMDB正式库风险太大（万一某天没有自动发现到这个实...

CMDB在容器场景下，确实面临一些挑战，与传统的虚拟机比较。由于容器进程的IP地址经常变化，CMDB里记录的应用IP地址就不是很合适了，为此也有一些企业对容器网络做了定制，要求容器Pod IP地址在Pod重建之后保持不变。这个诉求现在也有一些解决方案，在公有云上就可以通过将弹性网卡...