本文作者：中信银行数据中心 黄湘武 周海鹏
编者注：本文转载自《金融电子化》杂志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时代，科技的使命是引领业务。云平台是对基础设施的一项巨大的创新，将云计算的灵活性与银行管理的严谨性相结合，攻坚克难，通过云平台打通审批流、技术流，实现标准化、参数化的自助式服务。云平台就是基础设施变革之“纲”，纲举目张，支撑云数据中心架构转型。