首先你们使用CMDB是否支持分布式，如果不支持需要修改的话，那么建议还是使用开源的分布式配置系统，老版本的 CMDB 逐步替代掉吧。

CI如果是持续集成的含义的话，CI属于研发测试的项目管理工具范畴，其实应该独立于CD和CMDB，http://www.talkwithtrend.com/Article/243367  这篇文章值得参考。

CMDB中配置项之间关系通过一张张表来记录，这种方式的优点是配置项之间的结构清晰，关系明确， 缺点是各配置项之间关系的梳理是一个复杂的过程，我们在做CMDB的时候就相当于做标准化的过程，并能仅仅告诉研发和运维怎么怎么做，如果没有一个系统强制要求他这样做那么之前的流程和标...

1，企业下决心使用CMDB ，应该明白这样的事实，CMDB是一个不断更新完善的交付过程，肯定不是一个产品或者一个平台，能让它正常运行的前提条件就是有1-2个人，成天围这个 CMDB 平台在做各种更新完善和维护；2，CMDB 在企业内容使用，就一定是不完备、不完整、不一致、不鲜活，因此需要各...

如果CMDB数据粒度覆盖数据中心的话，就不可能是实现数据标准化。但是硬资源数据的确是可以将数据粒度标准化。不过企业都期望标准化，或者说追求优化成标准化的过程。

模型数据和关联关系，一般模型数据可以修改，但是关联关系要改到关联模型的冗余相关联信息，其实挺有难度，而且关联关系层次越深，修改难度越大。建议就是仅更改目标模型，维护关系，不要涉及关联关系其它模型使用冗余字段进行更新，否则很难保证数据的鲜活性和一致性。...

集中体现在CMDB的数据上：1、数据架构。例如数据结构，字段，关联关系等2、数据录入、增删改的方式。例如流程驱动、自动化发现、人工维护等3、数据校准方式。例如人工核查、自动化核查4、数据维护组织架构。5、数据管理制度。6、数据标准化制定。7、数据的用户。例如各类运维...

容器云下的CMDB，在http://www.talkwithtrend.com/Question/426651 有相关的讨论。个人感觉devops、微服务确实对传统CMDB带来冲击。但另一方面，CMDB本身在运维环境中主数据的价值不变，抓住这个主要矛盾就可以在新场景中重新找到定位和契合点。...

首先，CMDB一定是一个类似于自我学习+过程，绝对不是一个产品，不是一个技术，更不是一个规则或者流程所能落地的，倘若那个客户那的CMDB是一个产品、某个技术或者一个工具、流程、规则落地的CMDB，那么这个肯定是不好用的，也是不够完整的CMDB，更不是准确的CMDB，至于好用不好用，能不能将...

容器云的CMDB管理我们也在摸索中，欢迎大家一起交流探讨。前面有个讨论贴讲到CMDB定位和价值跟传统虚拟机时代有所变化。容器环境中，docker实例是短生命周期的，封装的也较好，一致性强。仅从登记角度，个人觉得不必追求细节或者实时。如果是大二层扁平网络，由于IP外部可见，可能通过...