分类： 架构设计与优化
2018-05-29 13:58:52
CMDB存储与管理企业 IT 架构中设备的各种配置信息，为运维场景提供配置数据服务，它与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值。好的CMDB建设可以发挥很大的价值，本文提供一种新的建设思路，供大家参考。
本文来源于——学领未来
覆盖不足：配置对象、对象属性和关联关系无法自定义扩展；
管理复杂：要求纳管的配置项过多，配置管理流程复杂，需要有专职的配置人员（配置经理、配置管理员）来维护CMDB，而配置数据价值难以体现，企业一般难以单独投入这些资源；
数据质量：数据的准确性与一致性较低；
配置孤岛：配置数据仅仅存储静态资产信息，没有把配置消费起来
首先是视角的转变，传统CMDB是围绕IT资产为核心进行建设的，无法与业务进行挂钩，体现不出多大的价值。而新思路视角则是以应用为中心进行，围绕应用来设计模型、配置项、模型关联等，以及建设配置数据消费场景，充分体现CMDB的价值。
第一步是建立业务场景，必须想清楚建设CMDB是为了什么，仅仅是把数据存放起来以便需要用的时候查看？配置数据应当发挥更大的价值，如基于CMDB建设自动化运维场景、结合监控做可视化大屏等；
第二步是建立模型蓝图，即CMDB中需要包含哪些内容。其中包括模型设计，如应用、中间件、数据库、虚拟机、物理机、网络设备等，关联设计，如应用与中间件的关联性、虚拟机与物理机的关联性；
第三步是建设CMDB工具，需要有一个高度灵活、高性能的CMDB工具，可以进行模型的动态扩展、配置项的动态扩展、模型关系的动态设置，以便适应企业的发展带来的变更；
第四步是建立模型以及数据梳理和录入，也就是要把之前设计好的模型蓝图，在CMDB工具中落地，并梳理好实例数据进行初始化录入；
最后一步是将CMDB与各个系统打通集成，落地规划的业务场景，让CMDB充分扮演好它的角色，持续的驱动配置数据的价值；
模型设计中，模型对象一般包含：应用、集群、模块、进程、软件包、中间件、数据库、虚拟机、物理机、存储、机柜、机房等。模型对应的CI不宜过多，原则是业务上必须用到的保留、可自动化采集的保留、可有可无的尽量舍弃。
关联设计中，以应用为出发点去进行设计，如下图所示，自下而上，直接或间接影响业务应用的因素一目了然。
CMDB工具建设好了，配置数据也落地了。但配置数据的维护是一个很有挑战的事情，因为我们不仅需要维护频繁变更的配置数据，还须保证数据的准确性和一致性。这里提供几种方法来改善这个问题。
数据的规则校验，这种方法可以在一定程度上提高数据的准确性，防止误操作或不规范的录入行为造成数据质量问题。比如正则校验、类型校验、必填和唯一性校验等；
自动采集，利用脚本、接口、协议等方式自动采集配置信息，降低人工维护成本的同时，可以极大提高数据的准确性；
外部系统集成，如与流程平台、资产系统、网管系统等做集成，将无法自动采集的配置信息通过接口同步的方式自动录入；
周期性的与基准信息进行对比，分析出差异并进行告警；
配置的自动采集依赖于采集工具，可以采用第三方的采集工具，但更灵活可控的方式是自己开发一个采集工具。如果是一种扩展性较好的一种采集工具的架构方案。
1. 在CMDB的旁侧，建立配置自动采集工具，通过接口的方式与CMDB进行集成；
2. 同步原理是每次从两边分别获取全量数据进行对比分析，这样可以保证同步的一致性。防止因为初始化或工具的问题导致同步误差；
3. 采集工具拥有配置采集器、数据获取和上报、数据对比分析等核心模块，通过任务调度模块的周期性驱动，让各个模块协调工作，定期的完成数据的采集、对比分析，将增量（增加、改动）的数据同步至CMDB仓库；
4. 配置采集器的设计，可以让工具扩展性更加良好。针对不同的采集对象，定制开发不同的采集器来进行横向扩展；
5. 通常采集的方式有脚本执行、接口对接、通用协议、数据视图等方式；
前面说到，配置数据消费非常关键，是一个CMDB项目成败的关键。那么基于CMDB我们可以做一些什么事情？
举些例子：
l 做应用的故障分析时，需要用到应用的拓扑信息；
l 做服务器资源自动交付时，需要用到应用、集群、模块等配置信息；
l 做巡检需要用到巡检对象的配置信息；
l 结合监控可以做业务的可视化大屏展示；
l 应用的发布、扩缩容等，需要知道应用部署在哪些服务器以及相应服务器的配置信息；
l 自动化运维工具的建设，也需要用到各种配置信息。如数据库的操作管理，需要知道有哪些数据库以及它的IP地址、数据库类型、实例名等配置信息；
本文提供的建设思路，其关键点是视角的转变，将传统以资产为中心的大而全的CMDB，转变为以应用为中心，更自动、更轻量的方式来进行建设，将更多的精力关注在数据的消费和价值的体现，从而让CMDB在企业的IT架构中发挥更重要作用。
