我们公司的逻辑资源基础单位是操作系统实例。一个操作系统上可部署多个中间价或数据库实例，但他们都只能归属一个产品，不能分别归属多个不同产品。这是基础管理规范约定的，这样的话就可以让操作系统和产品形成多对一的关系。而操作系统和物理主机也是多对一关系，哪怕虚拟机会...

借鉴意义不大。类比vmware的vcenter，通过接口或者数据库可以抓取到其配置信息。一个是范围小，主要是资源池方面的，另一个是单纯，无需面对企业内不同运维团队和部门竖井。企业内CMDB面临的局面要复杂的多。...

CMDB自动发现数据是否能够自动更新，取决于你的业务需求；如果你的CMDB供给给自动化操作的场景，CMDB发现的数据直接写入到CMDB影响会很大；2.我们现在的做法是先放入到自动发现数据库，人员审批后自动更新到CMDB；3.未来根据使用的情况，如果发现的数据都是可以直接更新的，我们可能会采...

从复杂关系的展现上说，肯定图数据库来实现比较好。印象里优维科技CMDB就是率先采用图数据库实现的，但没体验过效果未知。从理论上，关系型数据库也能实现多对多、一对多。只是要有中间表，有一定维护成本。深度路径查询肯定没有图数据库的效率高，还有许多其他劣势，也许图数据库是...

无agent优点无需多说，无入侵，部署成本低，等等。但如果non-agent能搞定数据采集，这个世界早就天下大同，不需要agent了。正是因为实际现状决定了，要抓取到丰富的信息，目前只有agent方式，以高权限执行。目前了解到商业CMDB也都是以agent方式为主。...

我们对CMDB有一个定位：主数据（因此不要什么数据都放到CMDB中）两个原则：1.CI属性最小化原则；不会被访问的先不放进去；需要时进行扩展2.以应用为中心原则；定好模型后，以应用为单位进行推广和实施；我还有很多的配置属性需要管理怎么办？基于CMDB建设对应的配置管理工具，如Puppet可以实现...

这个话题很大，其实前面很多讨论已经分析了细节。CMDB数据准确性要通过数据治理，所谓治理是一个系统性综合工作，总体可以概括以下几点：首先要提升CMDB数据战略地位，明确数据价值，凝聚共识，利用组织的力量来推动工作。二是明确数据项对应的职责。建议逻辑资源以产品为边界。三是根...

您说的很对。事物建模就是对象+关系，对象包括属性+方法。而事物的复杂度主要体现在关系的复杂度上，因此越是复杂的运维架构，到不是其属性太多，而是关系太复杂。逻辑资源和物理资源间的关系，应用之间调用关系，应用内部模块的关系，系统服务和业务流程之间的关系，等等。但通过CMDB体...

“如何把CMDB用起来？”个人的一点体会是：假如CMDB孤零零的立在那儿，技术再牛，数据再准也没用。CMDB的价值是依附在具体运维环境土壤中的，价值有两条腿：一是主数据库，二是工具和流程的场景。从这个意义上说，CMDB技术上可以标准化，但要是融入真实运维环境发挥价值，必须做许多深入性的...

CMDB一定是分步建设的。原因是CMDB主数据库的本质，决定了它不是孤立的事物，其价值由相关的运维系统和管理生态决定，公司的运维环境是CMDB发展的土壤。企业里一些原始管理手段的矛盾还没爆发时，请严格控制项目范围，摆正预期。要知道你的作战对手有深厚的群众基础，生产力决定生产...