银行祖传老系统很恐怖？也许你可以这么构建CMDB
随着金融科技快速发展，银行服务向“智能化”积极转型，银行IT积极引入云计算、分布式、容器、机器学习等新技术支撑业务快速发展。
对于运维配置数据管理（CMDB）的要求也从简单的辅助支持资产管理、导出基础数据查询报表，逐步转变为支持数据中心满足更加严格的安全运行标准，应对日益扩张的运维规模，掌握日趋复杂的系统架构的重要运维工具，同时CMDB也在自动化工具平台和智能化运维体系中扮演不可或缺的重要角色。
在某银行的智能化运维转型的过程中，提出以基础数据为根基，以数据治理为思路，围绕运维对象构建对象模型的配置管理思路，配合自动化运维平台，将运维对象与模型、监控、流程衔接，实现监、管、控一体化管理。后续也将结合运维Paas云平台、DevOps、CI/CD等工具，为科技转型打下坚实基础。
本文将结合某银行的实际工作阐述其在配置管理建设过程中的实践经验，与新技术下的探索。
充分利用专业配置管理库，构建CMDB分级管理模式：
与其他大型机构的发展历程相似，某银行的CMDB建设也经历了曲折的过程，在传统的台账式管理的基础上，该行CMDB建设面对的不是白手起家、一无所有的困境。而是面对若干个不同平台不同产品的专业配置数据库，以及前代配置管理系统留下的准确性存疑的若干数据以及依赖于配置管理信息的若干流程。
如何最大限度的利用现有资源，避免重复建设和浪费，清理历史配置数据，使流程能够更好的利用配置数据流转，成为了CMDB建设的最大难题。
为了更好的建设CMDB系统，我们针对各专业配置数据库开展了深入调研，并向各专业团队收集意见需求，针对较集中的提升CMDB数据的专业性、易用性、准确性的建议。我们根据领域，划分并建立了符合专业团队需要的专业配置库，以及相配套的数据维护流程。
但由此也带来的跨专业领域数据管理难度大，不易获取等问题。为解决跨领域数据的管理问题，我们从CMDB的架构设计入手，在专业配置库之上，建立“中央”配置库来进行跨专业领域数据的统一管理。
“中央”配置库具备灵活、精简、可变、易扩展的特点。
我们在“中央”配置库中构建配置关系模型，辅以各类数据校验、配置基线、报表等自动化工具；
并通过制定统一的数据标准和管理规范，来更好的满足因业务增长和技术更新而带来的对配置信息的需求和快速响应。
一、CMDB系统架构
CMDB架构由“中央”和“专业领域”两层组成，各层级的管理职责明确：
“专业领域”负责数据的采集、初步校验，并向“中央”供给数据；
“中央”CMDB负责配置信息的集中收取、存放、处理、展示、并向数据消费场景进行供给。
通过分工，“专业领域”CMDB可以根据各个运维领域的需要，更加灵活的使用工具获取运维对象的数据，“中央”CMDB不必关注以下问题：
面对不同领域的配置数据，如何取舍，如何获取；
采集端是否要与其他管理工具的代理共用，是否满足功能需求，是否与其他代理冲突，是否占用运维对象的资源；
采集的数据是否满足专业团队使用需要。
图一：某银行CMDB架构示意图
“中央”CMDB在集成了“专业领域”CMDB的数据后并非简单的将数据导入、导出，而是借鉴数据治理的理念，在数据标准、数据生命周期管理、数据准确性、数据展示、查询性能等方面进行了大量工作。
二、CMDB主要特性
在CMDB建设之初，有关运维配置的文档只有一份简单的管理制度和一页数据维护流程的使用手册，来自不同渠道的所有历史配置数据按照不同类别存放在数据库中，要从中提取任何数据都需要经过复杂的加工过程，其中的性能和准确性还得不到充足的保障。
为更好的对配置信息统一管理，我们提出了相应的管控原则与标准规范：
分级管理：“中央”CMDB关注信息的广度以及跨领域的数据关系，“专业领域”CMDB关注数据的深度。配置项按等级进行区分，其中应用场景越多的数据，重要程度越高，后续在维护和校验中花费的精力也就越多；
数据遵循生产与消费原则：各专业团队负责本领域配置数据的生产，“中央”CMDB作为配置信息对外消费的唯一提供者。数据遵循谁组织、谁提供、谁维护的原则，确保每一个配置项责任到人。
数据分类：将配置数据划分为技术属性和管理属性两个分类，并制定不同的管理标准和维护方式。技术属性数据属于客观数据，必须由系统自动采集；管理属性数据属于主观数据，由人工维护，但需要配属相应流程进行管控。
另外，在标准规范方面，也进行了细化，为使数据可更广泛的应用于各类使用场景，避免因统计口径造成的差异，明确了各类数据的使用标准。
并且，统一数据来源，各消费场景必须使用源于“中央”CMDB的标准数据。此外，我们也定义了数据交换的接口标准，降低数据传输的成本。
为了有效管理海量的数据，更好的满足应用场景对于高频热点数据的使用需求，从CMDB项目建设伊始，我们就建立了一套完整的数据标准、分级维护、回收下线的机制。
其中核心部分就是针对不同级别的数据建立不同的存储、校验、展示机制。这里面包含以下核心功能：
配合流程报表系统，统计数据关联的应用场景和场景调用数据的频度；
通过多副本，固定视图，提前导出等方式满足数据使用需求；
对于使用频率较低的数据，我们会降低其更新校验的频率，并逐步将其转移到次级乃至离线存储上，最终从CMDB中将此类数据淘汰。
数据生命周期管理的原则是从使用场景出发，倒推配置数据的重要级别、调用频度，根据级别配属相应管理手段和使用策略，以达到有效管理的目标。这与当前业界从应用场景出发梳理配置管理数据的思路不谋而合。
数据准确性一直是CMDB建设的核心难题，长久以来，依靠人工维护的配置数据一直受到准确性的质疑，进而造成“用的时候不敢用”，“用不上就没必要维护”的恶性循环。
为了解决此类问题，我们首先在数据标准中提到，CMDB的数据分为技术属性数据和管理属性数据：
技术属性数据是通过技术手段，由采集端直接在运维对象上采集的数据（如操作系统版本，CPU数量等），这部分数据属于客观数据，内容准确可靠。
管理属性数据是由运维人员在系统中人工维护的管理信息，如：应用系统名称，管理人员信息等。
技术属性因采用技术手段获取，数据准确性可以得到保证，在数据发生变化时，采用系统校验、管理员人工确认相结合的简便管理方式。而管理属性的数据则是数据准确性的重点攻坚对象，CMDB通过自动校验、定期提醒，流程控制、人工检查以及管理手段等多个举措来保证数据的相对准确。
从以上描述可以看出，技术属性的数据与管理属性的数据相比较，其在准确性、管理成本、收益等方面都具有较大优势。因此，我们数据准确性管理的核心就是尽量通过技术属性数据来替代管理属性数据。
当然，除此之外，保证数据的单一途径获取，利用规则校验引擎进行数据合规性的校验以及通过冗余数据进行数据对比、异常数据的及时管理确认等常规手段，也是运维配置数据质量保障的可靠方法。
“中央”CMDB的另一个重要功能就是数据的查询和关联展示。
通各领域数据，建立配置信息关联关系，通过配置项与配置项之间的关键字段，将原本分散在各专业领域的孤立信息，以应用系统为原点有机地关联起来，形成配置信息的网络。
在整个配置信息网络中，我们能够实现任意两个配置项的端到端查询。例如，我们可以清楚的知道应用系统都运行在哪些服务器上，这些服务器都使用了哪些存储，通过哪些网卡与交换机连接，以及这个系统都有哪些交易，哪些批处理任务，都部署了哪些监控，以及是否有对外的第三方业务等等。
图二：数据关联展示示意图
面对CMDB管理的海量数据，数量众多的数据接口和数据调用需求，庞大的规则校验、数据比对批量，以及部分应用场景的实时查询、实时更新的需求，CMDB的性能问题也理所当然的摆到了桌面上。
经过不断的建设调整，我们从以下几个方面着手，解决配置数据在使用过程中的性能问题：
除了对热点数据的专门存储和保障之外，面对众多外围数据消费系统的批量数据需求，从原来的单一接口、定制开发的方式逐步转变为提供通用接口供外围系统调用，最后通过通用服务的方式进行数据提供。另外通过通道、队列、定时等机制对于数据消费的异步需求进行充分打散，降低系统峰值期间压力。
在CMDB建设之初，我们也使用过厂商提供的标准数据处理组件，但在使用过程中发现其中能与该行数据消费场景贴合的部分比较少，反而由于过度的定制化，造成数据管理优化的困难。后来我们将CMDB转移到了传统的关系型数据库上，通过自主开发，在满足数据使用需求的同时，优化数据管理，提升了CMDB整体使用效率。
后续考虑到复杂的数据使用场景不断增加，以及数据管理要求的不断提高，可能会引入非关系型数据库进行数据处理，但是就目前而言，在技术真正成熟之前，CMDB会保留在目前的平台上。
解决数据性能问题的根本方法就是通过顶层设计，提前设计好各类数据消费场景的数据源和获取途径：
针对联机实时查询的数据，建立多个副本降低对“中央”CMDB的性能依赖；
针对批量数据，尽可能将数据加工校验的需求分散到不同平台，降低“中央”CMDB的批量压力。这一点我们也是在后续的建设过程中逐步摸索完善，并在下一代CMDB中彻底解决。
三、CMDB使用场景
某银行的CMDB目前已经为监控、批量、灾备、资产、自动化工具等多个运维领域提供基础数据服务。
其中比较典型的包括，变更和事件的关联影响判断，如此前部分网络核心设备变更，涉及多个安全域和众多应用系统的服务器，每次在变更实施前都需要进行反复确认，后续通过CMDB导出关联关系后，业务影响和保障需要一目了然。
之后，在此基础上又通过运维自动化工具建立了场景式的一键式验证工具，极大的降低了一二线的工作负担。
随着私有云和虚拟化技术的不断应用，更多的运维对象通过“资源池”来管理，那么如何管理基于动态分配的设备资源信息，如何掌握“超分”状态下每一个虚拟分区的配置信息，需要CMDB平台进行更多的考虑。
某银行分级CMDB在处理此类情况上具备天然的优势，本身云平台就提供了部分配置管理的功能，而“中央”CMDB只需要将云平台作为新的外部配置管理库接入，就能获取到相关的数据，那么后续的关于数据分级、加工校验再到供给到应用系统就是CMDB本身正常的处理过程。
近年来，各大数据中心不断实践“敏捷开发”、“持续交付”、“DevOps”等理念，对传统的流程、工具、运维模式等方面都产生了较大的冲击。
在这场变革之中，CMDB也发挥了举足轻重的作用。其灵活快速的投产方式在支持业务发展的同时，也带来业务模式、应用架构、服务状态、风险控制、工具有效性的一系列变化。
如何既保证业务需要，又做好运维的风险识别与控制？
CMDB通过关于应用结构，网络流量路径、设备进程端口资源的关联展示提供了一张立体的运维全视图，确保应用变化的一举一动都在掌握之中。
同时，CMDB也满足了后续自动化投产发布工具准确获取操作对象，监控变更前后对象变化等相关功能，为运维自动化提供了有力支持。
四、CMDB面对的挑战
后续运维智能化转型，需要充分利用容器云平台、私有云、大数据挖掘分析等手段，其中将广泛使用“资源池”、“共享服务”、“自动化发布”等功能。
为了既能看到运维的整体状态，又能深入到每一个具体的设备、服务、端口，掌握运维动态中的每一点变化，CMDB需要不断提升其功能和性能，提供更多更好的数据加工、展示方式，提供更加有针对性的运维场景。这些都是后续CMDB要不断探索研究的目标。
后续某银行也会持续加强CMDB的投入，更好的为智能化转型提供支持。
作者：匠心独运维妙维效
来源：匠心独运维妙维效订阅号
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
想了解更多运维场景的实操演练
灵活思考解决问题
不妨来Gdevops北京站学点独家技能
↓↓点击链接了解更多详情及报名↓↓