cmdcmdb开源自动化运维平台运维管理平台开源(cmdb开源自动化运维平台)

cmdcmdb开源自动化运维平台运维管理平台开源(cmdb开源自动化运维平台)

cmdcmdb开源自动化运维平台运维管理平台开源(cmdb开源自动化运维平台)

中国人民银行清算总中心上海中心运行部总经理 冯烨

CMDB面临的挑战

随着支付系统架构的日益复杂,以及更多分布式应用的投产运行,运维管理的复杂度越发凸显。实现数字化转型,提升决策和处置效率,成为清算总中心信息工作重点之一。

配置管理数据库(以下简称CMDB)是运维数字化的基础。CMDB中存储和管理企业所有的IT数字资产,它与业务运行、运维操作和运维流程都紧密关联,支持运维流程运转,发挥配置信息的价值,同时依赖于运维流程来保证数据的持续准确。在ITIL理论和实际实践中,CMDB通常位于运维管理平台的核心位置,已经成为金融行业运维管理的必备工具之一。在IT系统架构复杂、规模庞大的企业或组织中,是否具备统一视角的配置信息管理系统,并对其他IT管理平台起到基础支撑作用,是反映其IT运维管理水平高低的重要表现。

支付系统的CMDB建设虽然从2012年就开始了,但应用效果并不理想,对CMDB抱怨最多的主要问题涉及三方面:数据质量问题、工具问题及实施路径问题。

1.数据质量问题。CMDB数据的丰富性、准确性无法满足需求,是CMDB应用效果不理想的主要原因。

对于配置丰富性问题,因为配置数据模型缺乏标准,所以实际应用过程中,往往出现面临两难境地的局面:使用复杂数据模型,则维护困难,长此以往难以为继;使用简单数据模型,则使用场景非常有限,难以满足容量规划、运维排障、变更分析、安全合规等业务的深层次需求。

2019年,在建设支付系统新一代CMDB项目过程中,适逢中国人民银行科技司发布了《金融IT基础设施数据元》规范,对IT基础设施配置数据做了细致的规定,项目组在设计配置数据模型时,将此规范作为重要参考依据,并以此规范统一要求各参与方的配置颗粒度。

对于数据准确性的问题,根本原因是数据未能体现价值,“数据维护者并不是直接受益者”,所以大部分数据维护者缺乏主动更新配置数据的动力。因此项目在自动采集方面下功夫。通过综合考虑现有实际情况,采用了对于数据准确性较高且配合度较高的运维工具,尽量复用其数据采集能力,其他情况下主要依靠CMDB自带的数据采集工具,以保障项目进度的策略。

另外,除了坚定不移地推进自动化手段改善数据质量外,我们也清醒地认识到配置数据不可能实现100%自动维护,也不可能100%准确,所以数据质量核验工作非常重要。近两年中国人民银行科技司推动的“金融业科技信息报送工作”是提升配置数据质量的驱动力,其中涉及的5000多条数据核验规则已被总中心CMDB直接使用。

总体说来,随着自动化手段的日益丰富、《金融IT基础设施数据元》规范落地,以及“金融业科技信息报送”工作的持续开展,数据质量问题在逐步得到解决。

2.CMDB工具问题。传统CMDB工具易用性差,数据消费的难度大、门槛高。主要体现在搜索和数据呈现方式对用户不友好。用户的使用场景是丰富的、多变的、生动的,而传统CMDB的界面是枯燥的,CI概念是抽象的,结构和关联关系是晦涩的,使用门槛高。

在项目建设过程中,项目组坚持CMDB首先要围绕数据消费场景。但知易行难,传统的应用开发模式无法快速响应多样且快速变化的场景需求。对此,项目组决定引入全新的技术平台,即低代码应用构建平台,用于快速交付各种数据消费场景。实践证明,这种新型的交付模式极大地提升了效率,原本需要数个月实现的需求,现在只需要几天就能实现。甚至不少应用场景是CMDB使用部门自行搭建的,这使得CMDB的建设成果能够被快速应用、验证和迭代。

3.实施路径问题。CMDB建设的本质是数据治理,需要有长期规划蓝图,坚持步步为营、稳中求进。Gartner在调研全球175家实施了CMDB的企业,发现其中约75%未达成预期目标,核心原因是缺乏合理的路径规划。因为试图一次做太多事情,所以分散了精力,又缺乏阶段性价值产出,导致建设及优化工作不可持续。

CMDB的规划实施演进有五个阶段,各阶段的业务特征和能力重点见图1。

cmdcmdb开源自动化运维平台运维管理平台开源(cmdb开源自动化运维平台)

图1 配置管理发展阶段

支付系统配置管理起步较晚,项目开展前基本处于阶段1水平,各技术团队分散管理数据。因此项目一期核心目标是建设统一的资源配置库并建立与应用的关联,实现资产配置数据的统一和标准化管理,满足各部门对配置管理的基本需求,将配置管理水平从阶段1提升到阶段3。

建 设 过 程

支付系统配置管理数据库项目于2020年3月正式启动,12月完成预定目标,配置管理水平达到阶段3。项目建设过程中,工作重心主要在以下方面。

1.组建“一个团队”。为了避免CMDB脱离实际需求,在运行部门的统一组织下,召集不同技术条线部门的业务骨干成立联合项目团队。项目成员按照机房环境层、基础资源层、应用层等领域进行了详细的任务分工,各成员负责领域内的模型设计、接口设计、资源摸底等,协同工作、发挥领域优势。同时各技术条线整合配置数据并发掘关联关系。在模型设计、配置数据获取的过程中,负责各个领域的项目成员积极分享技术知识,结合自身运维经验,明确关联各层次模型对象的关键数据和获取方式,从而得以成功实现“从应用到机房”的配置项关联挖掘。

2.围绕“一条主线”。配置管理涉及的专业领域众多,需求零散。为确保CMDB建设的方向性,需要一条主线贯穿始终。项目组按“资源的全生命周期”这条主线来规划CMDB的闭环管理流程,包含设备上架、资源申请、资源部署、资源纳管、应用发布、应用/资源下线等各个环节,设计CMDB与其他运维平台和运维工具的数据交互,明确数据管理职责,通过与流程集成及自动采集手段,实现配置数据的自动更新。

3.建设“四大模块”。CMDB按功能层次结构可分成数据采集、数据存储、数据服务和管理运营四个部分。

数据采集:指通过配置自动发现功能,直接从网络设备、服务器、操作系统、虚拟化、存储、安全设备上采集配置数据,节省数据维护成本。另外,数据采集模块与Vcenter、Openstack等虚拟化和云管平台对接,获取配置数据。

数据存储:设置临时库和生产库,外部数据接入后缓存到临时库,通过数据调和引擎(CP)对临时数据进行清洗和转换,并将处理后的数据更新到生产库中。

数据服务:针对日常查询维护、关联分析、资源统计、应用保障等不同的使用场景,提供相应的数据服务能力。针对集中监控、变更流程、大数据智能分析平台等工具消费需求,可通过数据API接口超市迅速满足数据消费需求。

管理运营:建立全面的数字化、可视化运营报告,掌握配置数据的准确性情况。

建 设 成 果

经过约9个月的建设,构建了跨越应用、系统、网络的一体化配置数据模型,完成了70余个配置表单的设计,涵盖了应用系统、计算、存储、网络、基础设施的相关数据模型。自主编写、优化了各类基础资源配置采集脚本,做到了CMDB运营和扩展的自主可控。其中特色成果简要分享如下。

1.百川与星海。“百川”“星海”是项目组为CMDB两项重要数据服务的命名,这两项数据服务对良好的数据消费体验、形成数据管理闭环至关重要。

“百川”服务,既有百川灌溉也有百川入海之意。所谓百川灌溉,是指数据滋养业务,配置数据能够“流入”用户日常工作中。“百川”服务基于低代码应用构建平台,用户根据自身业务特点创建自己的数据应用场景,过滤不必要的数据,屏蔽复杂的配置管理概念,突出易用性,使数据贴近需求,真正赋能业务。同时数据遵从统一的数据模型、流入统一的数据存储,被CMDB统一管理,实现“百川入海”。

“星海”服务,寓意是星海成图,目的是将离散的、难以理解的配置数据以架构图的形式直观呈现出来,让运维人员能够一目了然看到各个IT组件间的依赖关系、相互调用关系,降低了数据的理解门槛,满足风险分析、架构优化、故障排查等需求。

2.与变更流程衔接,定向自动发现。将CMDB与流程平台结合是实现闭环配置管理的重要手段。项目组在应用系统上线、扩容、下线等几个场景上做了实践,取得不错的效果。

比如,在应用系统上线、扩容、迁移时,CMDB向变更管理提供“应用系统及关联的分区节点”数据,并获知需要变更的节点。当变更流程结束后,CMDB通过“定向”自动发现对变更节点进行数据采集和自动更新,从而保障了数据的准确性,也从另一个侧面验证了变更是否成功。“定向自动发现”是本项目的一个小创新,区别于传统的“全量自动发现”,是指将数据采集范围限定在近期发生过变更的对象,这样能够及时更新数据,在减少资源消耗的同时提升数据采集频率。

3.使用混合式图库实现高效关联关系查询。CMDB中存储了大量的关联关系,包括应用系统关联的OS、OS关联的主机分区、主机分区使用的存储资源、存储连接的网络设备、机柜位置和机房等等。如何实现关联关系的高效查询是CMDB的核心要求之一。传统的关系型数据库可以应对CI属性的检索,但是在关系检索方面性能较差,超过5层以上关系的检索几乎无法查询。为提升关系检索效率,业界一般使用图数据库,如Neo4j等数据库。但这种原生的图数据库不支持关系的逻辑运算,也不支持关系属性的全文检索,而这些检索场景在运维领域非常常见。

为解决此问题,项目组创新性地采用了混合式图库的技术方案:底层采用非关系型数据库,中层叠加图论算法,上层引入VQL可视化查询语言。这种技术方案不但解决了图数据库不能满足全文检索的业务需求,还能支持关系的逻辑运算,能支持非专业人员以图形化形式灵活设置查询规则。经测试,在目前数据量情况下,5层以内CI关系遍历的响应时间不超过10秒。结合可视化技术,实现5层复杂拓扑图一键秒级生成。

4.数据超市。除了提供配置数据查询和维护门户之外,CMDB还需要支持外部应用对配置数据的消费。为了满足此需求,项目组实现了数据超市:外部系统能够像采购商品一样“采购”配置数据。配置数据被事先“包装”好,放在“数据货架”上,成为“数据商品”,能够将以http的restfull标准协议“快递”给外部应用,实现数据的自由流通。

下一步工作

经前期建设,我们已构建起涵盖应用、系统、网络的一体化配置数据模型,通过与流程平台、云平台(Vcenter、Openstack)、HMC、网管等工具的集成和自动采集,实现了配置数据的初始化和持续更新,通过“百川”“星海”及“数据超市”等数据服务能力,为使用人员、运维工具、平台提供数据支撑。从CMDB总体规划蓝图看,总中心的配置管理水平已处于阶段3水平。

未来,随着云计算和分布式应用架构的进一步发展,IT管理规模和复杂度将继续上升,清算总中心将继续推进CMDB建设工作,将配置管理水平从阶段3提升到阶段4,为运维团队和运维工具平台提供更丰富的数据服务,更好地支撑运维工作,保障支付系统安全稳定运行。

(栏目编辑:张丽霞)

本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 sumchina520@foxmail.com 举报,一经查实,本站将立刻删除。
如若转载,请注明出处:https://www.sumedu.com/faq/249461.html