Menu Close

实战丨银行云平台建设难点分析与建设实践

本文作者:中信银行数据中心 黄湘武 周海鹏

编者注:本文转载自​《金融电子化》杂志2019年11月刊。

云平台建设难点分析

随着银行业务的高速发展,各银行都认识到云平台对于银行架构转型的重要性,都在大力建设云平台。银行业现有IT基础设施规模大,IT运维水平高,有着深厚的技术储备,这给其私有云建设打下坚实的基础。但银行IT系统资源上采用严格的管控方式,尤其是互联网类应用、交易类应用、MIS类应用、办公类应用在网络上彼此严格隔离;流程上采用基于ITIL的流程管控、专人专岗、多部门分工合作,有着严格的审批流程、严格的变更管控。这些特点与云计算的按需自助、软件隔离的大资源池、高弹性、高扩展性诉求有较大差距。银行在私有云建设时,从理念到技术,都面临巨大挑战。具体问题包括如下几方面。

1.银行普遍建立了基于VMware或KVM虚拟化的技术体系。在银行业强调网络隔离的环境中,容易出现集群分散、模板众多,管理难度大的问题;虚拟化只解决了计算虚拟化,而网络还大量使用传统VLAN隔离,交换机端口需要手工配置,难以动态调整;虚拟机发放需要在vCenter中手工操作,或借助自动化脚本进行虚拟机发放,不能实现延时变更、不能实现变更的全流程自动化、自服务,在银行严格的变更管理的要求下,变更需要投入巨大的人力资源。

2.私有云方案,来自公有云的技术体系,基于三个设计理念。一是海量容量,二是流程简化,三是压缩成本。这与金融行业IT系统的设计理念是有很大区别的,甚至是矛盾的。

(1)私有云希望一个机房只有一个逻辑资源池,通过VPC实现区域隔离,但银行中一个机房一般都有多个严格物理隔离的网络区域,每个区域中又有很多彼此隔离的网段。

(2)私有云强调自服务,一个租户对于其分配的资源有包括启动、停止、删除的一切权利,但银行中有严格的高权、低权划分,有严格的变更管理要求,一切操作要留痕,一切变更要有审批。

3.私有云方案默认只有一级审批,而银行中有复杂的多级审批需求。

(1)多级审批:银行中的变更,需要多个级别的角色审批。与单级审批相比,实现逻辑复杂很多,流程的复杂带来了技术的复杂。比如提交申请一个2T的云存储后,不能马上分配资源,只能预占用资源;如果在审批过程中被驳回,需要释放资源。

(2)双轨模式:对于资源申请,有需求提出者和实施人两类角色,流程上又有“需求受理”和“变更执行”两个流程。需求受理流程包括:需求方管理员、需要方组长、需求方处长、受理方处长、受理方组长、受理方管理员;这个过程是在审核资源申请的合理性。在审核过程中出现异议,需要将流程原路退回。变更执行流程:变更方案制订人、变更方案复核人、组长、干部、变更经理、变更实施、变更反馈。这个过程是在审核变更方案的合理性。最后变更需求反馈:变更受理方实施完后,需要按照与变更需求受理相反的顺序,进行反馈,也就是“原路来、原路回”。云平台建设时,需要了解原有模式的设计思想、管控点、风险把控点,根据具体云服务的特点进行分析和设计。

(3)分支审批:一个资源申请的变更,可能涉及服务器、网络、存储多个专业组,虽然我们追求一键式实施,但客观上,可能需要在主审批时,有独立的专业审批,各个专业在不同分支上进行审批。

建设实践

1.云管平台的定位。根据中信银行的实践,私有云的建设关键。是将资源层和云管层分开处理。传统的私有云厂商,关注的是资源层中的虚拟化、SDN、分布式存储这些底层技术。而在银行落地私有云方案时,更为重要的是通过云管平台将私有云与原有的管理系统、审批流程、监管要求等进行适配,形成一个银行底层资源和上面流程的对接总线,快速实现各种资源申请的服务化,在生产环境和测试环境快速推广使用。

对于底层技术,云管平台需要能够尽可能多地进行纳管,对于VMware、Openstack、SDN、NSX、F5、NBU等底层技术都有比较完备的接口和API;对于实体机、传统交换机、防火墙等就需要借助第三方工具进行管理。

对于银行的传统审批流程和新型的DevOps流程,云管平台要灵活应对。对于强调新流程的银行,可以采用“集成策略”,云管平台做为统一入口,实现DevOps、将开发、测试、运维打通,进行在线审批;对于强调传统流程的银行,可以采用“被集成策略”,流程平台做为统一入口,在申请资源时,跳转到云管平台。

目前各行都在建设自己的Iaas服务、Paas服务、容器服务。因为这些云服务具有很多共同的属性,比如服务的Portal,自服务的界面,与流程平台的集成,与资源池的对接。可以考虑建设统一的云管,实现统一的云服务Portal。

2.审批流程。本文以云管平台“被集成策略”为例,说明云管平台与传统基于ITIL的审批流程的结合。在此方案中,将银行已经建立好的流程平台仍作为云环境下的审批主体,将云平台的自服务功能嵌入流程平台的审批流中(见图1)。

图1 云管平台与流程平台的融合

具体的做法如下:

(1)在流程平台中,在常规变更、自动化变更之外,增加“云平台变更”的类型。

(2)云服务的需求方,提交“云平台变更”变更,页面跳转到云平台中,以自服务的方式,选择需要申请的资源,选择变更的时间(银行有严格的变更时间要求,生产环境不能在白天工作时间内立即执行),点击提交需求。这时需要把申请的资源进行锁定。

(3)云平台生成PDF格式的摘要,回到流程平台中。

(4)需求方在流程平台提交申请,按照原有的流程实行审核,其中变更需求可以从PDF文件中查看。

(5)审核通过后,流程平台将变更单号发送云平台,云平台在指定的时间内变更。变更完成后,自动回复变更单。

(6)如果审批不通过,则在云平台平台取消对资源的锁定。

在以上模型中,流程平台是流程审批的总线,实现资源申请、变更执行两个流程;云管平台是技术的总线,一方面对接底层的资源,一方面对接运维工具。

3.从自动化到服务化的提升。各银行一般都已经建立了自动化平台,变更的自动化率已经很高。云平台带来哪些提升,服务化与自动化有哪些不同?这是云平台建设中,思路转变上的一大难点;是划定云平台与自动化平台边界的一大难点;也是推广云平台使用的一大难点。

自动化首先是一个通用的运行平台,提供一套基于Excel表等形式为输入的通用执行平台。管理员根据每个变更的具体场景,制订不同的变更方案,提交不同的自动化变更。这种方式,好处是灵活,能够适应运维中变化多样的变更需求,是一种“自由格式”的自动化变更,不同节点上的操作可以自由组合。这种方式的缺点,第一是每个变更都需要手工编制方案,容易出现人为错误。第二是没有标准化,部门与部门之间,组合组之间,测试和生产之间,没有共享与传承,共性的经验没有积累下来。

云平台提供的自服务,是资源发放和安装部署场景下,针对自动化进行针对性改造,包括以下几个维度。

标准化:将测试环境和生产环境的安装部署工作统一起来,控制好需求、制订套餐,这与公有云的设计是一致的,简化才能带来高效,同时也留给客户一定的自定义的弹性。

参数化:对于一个特定服务,针对不同的场景,归纳、抽象出通用的输入和输出参数。实现一个通用的,有良好适配性的参数化界面。同时要保障其扩展性,实现参数可配置。

前端Web化:提供一个Web化的服务申请界面。要用通俗的语言描述服务的各输入参数,尽量屏蔽专业术语和底层细节;要能根据登录用户的预分配权限,显示其有权限的资源;要控制输入的有效性、保障输入的规范性。比如IP地址的输入格式,掩码的输入格式。

中台审批流:服务化后仍然是一种变更,为了进行留痕,要与审批流程相结合,要支持历史审批数据的导出,要支持外部审计。

后台技术流:服务化要屏蔽后端的细节,使用方不用关心实际执行是调用脚本、API、还是自动化平台,不用关心实施的细节,只需要提出需求。云平台会自动生成变更方案(见图2)。

图2 自动化与服务化的区别

从定位上讲,云平台聚焦基础设施资源,重点是新系统上线和资源类变更领域,通过底层系统的API,或者调用自动化平台脚本实现。自动化平台聚焦应用上线和日常变更。如果将常用的日常变更标准化、参数化后,可以发布到云平台,实现服务化。例如云平台对接VMware后,对于虚拟机hang死的场景,就可以实现一个虚拟机重启的云服务。再比如对于虚拟机扩文件系统这个需求,可以通过云平台进行调度,将虚拟机扩容,文件系统扩容的工作统一编排,形成一个云服务。

4.云管平台与DevOps。云平台的实施,首先带来了数据中心内部资源申请的自动化,将原本需要网络部门、存储部门、虚拟化部门实施的工作全部整合成一个对外的服务,可以一键式完成。

在强调敏捷交付的时代,云平台本身建设完备后,可以将资源申请前移到开发中心,与DevOps流程融合,实现资源申请的自助式服务。

实现以上目标,纳管了虚拟机和实体机的IaaS平台与容器平台有非常大差异。容器以应用为核心,一个容器就是一个可运行的业务单元;一个完整的应用环境,就是一组容器的组合。在生产环境,容器弹性扩容后,会自动进行以下操作,可以马上投入使用:环境参数的导入;业务的健康检查;服务的注册发现;通知负载均衡分流。

而对于虚拟机或实体机,当完成了系统的创建后,还需要一系列处理,才能投产,为了实现更好的DevOps,需要完成三方面的工作。

(1)服务的串接:例如将创建虚拟机的服务与安装部署Redis的服务串接,实现两个服务之间的参数传递,这样就支持了在没有虚拟机的情况下,申请一套Redis环境,实现了IaaS服务和PaaS服务的融合。支撑开发中心在DevOps的服务申请界面,选择所有需要的服务,云平台将各个服务对接起来。

(2)多节点部署和编排:例如配置分布式数据、Redis集群等PaaS服务,都需要在多个节点部署,需要支持多种高可用的部署方式,例如Redis有集群环境和哨兵模式。这些工作,需要在云平台内部实现。

(3)应用上线基础环境准备:一个应用的部署,需要先创建虚拟机或安装实体机、需要部署数据库中间件、需要部署监控与备份需要配置负载均衡、需要申请域名、需要加入堡垒机。为了提升敏捷交付的效率,云平台需要不断扩大云服务的范围,围绕的应用上线,进行服务的规划和设计,达到一个类似容器云的快速部署的效果。

总结

银行4.0时代,科技的使命是引领业务。云平台是对基础设施的一项巨大的创新,将云计算的灵活性与银行管理的严谨性相结合,攻坚克难,通过云平台打通审批流、技术流,实现标准化、参数化的自助式服务。云平台就是基础设施变革之“纲”,纲举目张,支撑云数据中心架构转型。

Posted in 多云管理, 案例