多阶段元数据一致性分析——助力北京银行实现IT运营效率提升

北京银行科技部门是如何借助元数据管理工具实现IT运营效率的提升,本文会对这个元数据项目重点建设内容进行介绍。

引言

还记得我们在《从三个场景看如何玩转元数据应用》文章中提到的第一个应用场景,元数据对比分析——让系统上线/变更高效、可控吗?还记得苦逼的程序员们在系统上线当天彻夜加班排查上线脚本问题的场景吗?我们给出的办法使用元数据对比分析场景来解决这类问题,那么北京银行科技部门是如何借助元数据管理工具实现IT运营效率的提升,本文会对这个元数据项目重点建设内容进行介绍。

多阶段元数据划分

首先来了解下多阶段元数据是如何划分的、存储介质有哪些,其实在元数据完整的生命周期中,有三个关键的形态,设计态、测试态和生产态。通过对元数据三个形态的管理,就能够实现对元数据全生命周期管理领域的重点覆盖,从而达到对元数据管理提纲挈领的效果。

三个不同形态是根据软件开发的不同阶段来划分的。软件开发一般分为需求、设计、开发、测试、部署上线和运维等六个阶段,在软件开发的三个关键阶段会产生不同形态的元数据。

1、软件设计阶段,通常会对系统的逻辑模型、物理模型进行设计,就会产生设计态的元数据。它的存储介质一般是ERWin、PowerDesigner之类的模型设计工具,再简单一点可能是Excel、Word文档。

2、软件集成测试阶段,会对系统功能进行测试,需要在测试环境部署一套系统,那么从测试环境获取到的元数据就是测试态的元数据。通常存储介质一般有关系型数据库,例如Oracle、DB2、Mysql、Teradata等等,复杂点的非关系型数据库,例如:MongDB、HBase、Hive、Hadoop等。

3、部署上线阶段,当软件部署到生产环境,投入生产运营。从生产环境获取到的元数据可以称为生产态元数据。生产态元数据存储介质和测试环境一般差异不大,只是换了一个环境而已。

接下来我将结合北京银行元数据管理项目案例进行具体说明多阶段元数据的管理。

北京银行急需提升IT运营效率

北京银行整体IT系统建设已经达到一定的规模,已应用的IT系统有100个左右。随着业务的不断发展,这些系统的日常变更也较为频繁,每周都会存在相应的变更上线操作。从管理模式上看,变更的管理是以系统为基础,以项目为中心进行管理,如何保证系统日常变更的设计与实施上线的变更的一致性,使频繁、复杂的系统上线变的简单、可控、可跟踪,从而使系统更好的服务于业务部门,是北京银行科技部门重点建设的能力。

多阶段元数据一致性分析保证系统安全上线

基于北京银行元数据管理需求,我们按照以管理流程为依据,以元数据管理系统为技术支撑,以事前预防+事后监督为重点功能的建设思路。通过流程的落地执行,实行对多阶段元数据统一管理,保障设计与实际上线变更一致性,来推进变更管理、IT流程管理规范化。

多阶段元数据一致性分析——助力北京银行实现IT运营效率提升

上图是北京银行多阶段元数据管理架构,通过这张图我们可以看清多阶段元数据管理思路以及实现多阶段元数据比对应用场景要解决的关键三个问题。

1、不同形态元数据的获取

借助普元元数据管理产品Primeton MetaCube强大的采集适配器能力,可以将不同形态的元数据采集到元数据存储库来进行管理。由于采集适配器不是本文的重点内容,这里不展开说明。

2、元数据变更管理流程

业务系统发生需求变更或功能模块升级导致表结构变更时,需要在元数据管理系统中发起申请流程,提交设计态元数据进行备案。功能开发完成后,部署到测试环境,由待发布环境元数据系统获取测试态元数据,将元数据变更在生产环境部署前与设计态元数据对比,比对一致上线部署,不一致驳回上线申请流程。元数据变更在投产上线完成后,生产环境元数据系统会采集生产态元数据,并再次与设计态元数据进行对比,实现对元数据变更的事后核查。通过三个不同形态元数据的比对分析,达到事前风险预警+事后变更核实的管理效果。元数据变更管理流程如下图:

多阶段元数据一致性分析——助力北京银行实现IT运营效率提升

3、多阶段元数据一致性比对分析

元数据一致性比对是实现多阶段元数据管理的核心功能,也是支持元数据变更流程核心功能。下图是元数据比对功能的三维立方体。对于不同形态、不同类型的元数据都可以实现比对,比对内容包括对象本身、对象属性、对象的关系等等。

多阶段元数据一致性分析——助力北京银行实现IT运营效率提升

多阶段元数据一致性分析实施方法

通过独立部署三套元数据系统环境,包括测试环境、待发布/准生产环境和生产环境,分别对应设计态、测试态和生产态的元数据管理。

测试环境

测试环境为非受控环境,用于各项目组的一些开发测试工作,项目组可根据需要操作元数据管理系统,测试环境的元数据不作为下游元数据的来源。

待发布环境

待发布环境为受控环境,操作人员必须满足相应的流程规定方可进行相应的操作。该环境仅对个项目负责人开放,用于提交各自上线方案中涉及的数据结构变更等应用。

生产环境

生产环境元数据完全是生产系统实际情况的反映,其数据的更新依赖于元数据采集过程,可采用自动采集或手动采集过程,但原则上不允许手工调整,最大程度保证其对实际环境的真实反映。

待发布环境与生产环境是元数据管理的重点,三个环境的元数据在元数据系统上线之初通过自动采集功能,统一进行元数据采集,此时三者存储的元数据都与生产环境完全一致。

在各项目的负责人发起元数据变更申请流程后,管理员需要使用元数据多阶段比对功能,此功能主要包括比对规则的设置、比对任务执行和比对结果展现三个功能模块。通过比对规则管理,设置比对检验规则,例如设置那些元数据对象、那几个属性参与比对,是否忽略大小写等。设置完规则后,选择要比对的两个元数据对象生成比对任务,比对任务运行成功后,便可以查看比对报告。如下图所示:

多阶段元数据一致性分析——助力北京银行实现IT运营效率提升

北京银行元数据管理平台建设效果

在没有建设元数据管理体系之前,北京银行一项系统变更要经过几轮评审后,才能够进行上线部署,且一旦上线变更与评审内容略有误差,导致ODS、分析应用等下游系统的被动调整,影响了整体IT运营效率,使得本来三天可以搞定的系统变更持续了一周。

元数据系统投入运行后,通过对三个关键阶段元数据的管理,使得IT部门能够及时的获知业务系统的变更方案,协同受影响的下游系统同时变更。使得变更上线简单、可控,提升了IT运行整体效率。

来源:业界供稿

0赞

好文章,需要你的鼓励

2016

06/21

19:06

分享

点赞

邮件订阅
白皮书