CMDB如何分层建模?在CMDB建设过程中如何抽象ci?

这个问题确实非常有挑战，我们并非专门的自动化运维平台软件企业，行内自动化运维开发团队所做的所有工作，都是围绕运维团队的需求，因此在需求广泛性、普适性方面不敢说做的很好，只是解决了目前内部优先级较高的几个痛点。接下来围绕我们在建设过程中的实践，谈一谈我们的实施思路。
1、目前行内的自动化运维体系已经涵盖包括CI/CD（也就是说CI并未在CMDB中实现，而是落地到了自动化发布系统中）、数据库、装机、巡检、APM、日志等常用模块，不过CMDB，我们是较后期才开始建设，主要原因有两点：
a>. 除了统一维护各类基础数据，并没想清楚CMDB该怎么用，需求都没想清楚，如何建就更无从谈起；
b>. 初期各运维系统的基础数据自已维护已可满足需求，尽管若能统一到CMDB，对于各运维系统会更为简单，但考虑到a这一因素，再加上运维开发团队这么三四号人，两三条枪，需求多的忙都忙不过来，也实在不舍得挥霍开发资源。
2、后期为什么建设，又有下面一些因素：
a>. 体系基本构建完成，保守点讲是常用模块都已解决了有无问题，当然下一阶段解决功能优劣无异是更难的挑战。但是这一阶段的完成让我们能够腾出手思考CMDB的实现。
b>. 自动化系统越建越多，基础数据维护的成本越来越高，因此希望建设统一的管理系统就提上日程；
c>. 金融行业的各种统计报表、巡检日志数不胜数，即便是运维团队也有大量文档性质的文档要输出 ，而基础数据未能结构化(或者分散在各个系统)，每次梳理都要耗费许多精力人力，并且过程痛苦不堪
3、最终建设时，主要围绕两点：
a>. 如何确保数据的准确性、一致性，我们的思路是将CMDB做为数据源头，将此做为红线，其它地方需要数据必须从CMDB中取，若CMDB中没有，该被数据就补，该加功能就加；
b>. 物理纬度和虚拟服务纬度结合。很多常规需求是以物理纬度，比如采购合同、物理设备、机房/机架等，同时运维同学日常大量使用的数据又是以系统/服务为主，因此设计时考虑这两个纬度为主视角开发各项功能。