银行云管平台有哪些架构设计难点和运维要点？

Posted 2021-04-10 twt企业IT社区

【摘要】 本文由来自银行业的实践专家介绍当前银行业云管平台项目的现状和趋势，分析如何进行成本评估，如何进行技术路线、产品的选型，以及云管平台架构设计的难点和运维要点。内容全面详细，可供正在规划云管平台项目的银行业同行参考借鉴。

【分享者】胡海光，就职于银行科技运行维护部门，主要从事X86服务器、虚拟化及云平台的日常运维管理工作。熟悉VMware、Linux、AIX、Db2及云平台等相关产品及服务。获得VMware VCAP认证、db2中级认证及H3C认证云计算工程师。

一、银行业为什么要上云管平台项目？

随着互联网技术的发展，AI、区块链、云计算、大数据等技术方兴未艾；对于银行业来说，在金融科技化变革的浪潮中，如何把握金融科技发展的脉络，是立足自身发展的必由之路。因此银行业只有紧随科技发展的步伐，不断提升自己的科技能力，才能应对科技日益变化的明天。但银行业普遍存在着以下现象：

1、业务规模不断扩大，设备保有量不断增加，设备的管理难度不断加大；

2、传统业务的小机池与分布式业务的PC池各自分散管理，缺乏有效统一管理；平台各异、重复采购、盗版严重；

3、停留在IAAS层面，PAAS层面应对乏力，缺少部分场景的灵活性和扩展性；

4、对现有使用设备缺乏有效的管理手段，竖井建设、低利用率；导致资源无法有效利用；

5、虚拟化层面部署虚机缺乏有效的批量部署安装功能以及有效的监控；运维分散、专业化低。

针对以上出现的情况，我们把眼光转向了云计算，云计算作为信息技术领域的一种创新应用模式，具备低成本、弹性、易用、高可靠性、按需服务等特点，目前云平台已经成为更多行业用户的基础环境和业务承载平台，越来越多的银行业也认识到云计算的价值。云平台最大的价值在于改变了传统的资源交付模式，实现了 IT 服务从资源到服务的转型，其中云管平台更起到了核心作用。一个好的云管平台是贴合用户实际需求的，它在提升 IT 资源利用率的基础上，实现了资源的统一视图管理，并且实现了与企业内部流程的融合和交互，最终实现云平台的自服务。

同时随着银保监“十三五”对于云计算架构平台迁移的要求，即到“十三五”末期，面向互联网场景的重要信息系统全部迁移至云计算架构平台，其他系统迁移比例不低于60%。因此银行业对于云平台的建设越显迫切。

云管平台实现了对传统资源交付方式的变革，然而云管平台的实施也遇到了诸如技术线路的选择、异构资源（X86 物理机、小型机、 多种虚拟化的虚拟机）的统一纳管、管控流程的标准化和个性化之间的差异等问题，诸如以下问题：

1、在故障自愈及弹性伸缩等方面，针对何种故障场景进行自愈，如何进行故障判断；以及弹性伸缩机制、伸缩机制适合的业务类型、是否涉及服务改造、集群改造等。

2、云平台的灾备或双活建设，面对跨机房型的容灾或双活，如何进行建设部署，是否满足业务要求等。

3、云管平台的自动化管理先进理念与老旧传统思维的冲突，大多数人安于现状，仍在用传统的老旧方法来进行全盘管理，虽也能实现效果，但耗费大量的人力物力，满足不了业务的要求，基于此只有从理念上进行改造，纠正人员的思想认识，接受云管平台这一先进管理方法，才能从根本上解决问题。

以及云管平台异构设备管理、设备版本不一致、建设维护成本及技术储备等诸多问题。针对以上云管平台存在的诸多问题，结合银行业自身的云管状况，在实践过程中也发现存在诸如多云或多虚拟化管理等痛点问题。对于多云管理来说出于历史的设计，或基于成本考虑，或防止被厂商绑架等原因。 

银行业实现云管平台能够有效整合和利用行业内部多种异构资源，统一纳管X86、power及其它虚拟化，简化内部IT架构，实现设备的全生命周期管理，消除设备使用信息孤岛，降低运维和管理成本；同时，结合云平台提供的自服务能力，能有效的提供设备自动化、批量化部署；应用自动化、流程化安装；第三方服务目录标准化、接口化对接；计算、存储及网络资源的可靠性、冗余性保护；故障自愈、弹性伸缩等多项功能并驾齐驱；全面的安全资源池保驾护航。

二、银行业上云管平台项目的多吗？现在是什么形势？

云管平台能解决银行中存在的特定问题，符合银行监管的要求，也能贴合银行的需求，因此就整个银行业来说，云管平台在大部分银行都已经铺开。大的银行早已经建设完成并投入使用多年，中型银行也已经完成云管平台建设并开始投入使用，而部分中小型银行则在不断调研，收集云管平台项目的需求，为云管平台的建设做好前期的准备工作，就整体情况而言，60%-70%的银行都已经在使用云管平台。

就云管平台项目在不同的银行中进展情况不同，究其原因如下:

1、 各个银行规模不同，因为银行存贷款规模不同，当达到一定的规模时，就会遇到虚拟化无法解决的问题，因此大的银行在比较早的时间点就开始考虑云管平台来解决一系列存在的问题，而中小型银行由于先天的规模限制，导致起步较晚。

2、 各个银行投入不同，对于大的银行来说，其技术人员较多，水平较高，对于技术的投入也比较多，因此人力财力都具备了，所以大的银行较早的上马该项目，并不断地投入人力物力来完善和丰富；而对于中小银行来说，人力和财力都不是那么充分，要考虑各类的预算支出，因此造成偏慢的局面。

3、 各个银行对新技术看法不同，自云管平台诞生以后，其理念在业界不断发酵和深化，各银行对此项新技术的看法不尽相同。有的偏向于保守先观望，看看别的银行是如何做的；有的偏向于拥抱新技术，研究云管平台能解决存在的问题和带来的好处进行综合比较，并开始着手调研后进行建设；有的则处于两者之间，在调研但没开始着手去做。故带来不同的进展情况，也有些小的银行走在部分中型银行之前。

基于以上几点考虑，对于银行业来说，云管平台项目不断在推进，持续在建设，努力在深化，在不久的将来可以预见到每家银行都会拥有自己的云管平台，在云的世界里向每个客户普及金融的乐趣。

三、银行业如何评估云管平台项目的整体成本？

在明确了云管平台项目的需求之后，就必须考虑如何建设好云管平台；对于云管平台的技术选型及相应的成本分析是之后建设的重点。因为只有确定好合适的技术路线才能确保实现制定的各项需求。对于云管平台的建设无外乎采用如下三点技术路线：

1、 购买厂家成熟的云管平台产品；对于大多数技术积累不够的银行来说，购买厂家成熟的云管平台产品是快速建设云管平台的一条捷径。对于大多数银行来说人力早已捉襟见肘了，而购买云管平台产品不需要投入较多的人力成本来建设和维护，因此对于该点的成本分析着重说明如下。

1.1 物理硬件成本：包含云管平台搭建的服务器、网络设备等直接成本，如银行有现成的服务器和网络设备等，则可以直接拿来进行使用；如无则需要进行单独的采购，其中服务器和网络设备配置需满足云管平台的要求。这里的物理硬件成本根据银行对于云管平台需求的数量而定，成本有高有低。

1.2 云管平台成本：对于向厂家采购的云管平台是需要按CPU或存储容量进行单独收费的，在采购之前需弄清自身的需求，对于云管平台上需要的虚机是要多少量，从而去估算服务器和网络设备的数量，再根据服务器的数量去估算要购买的云管平台license的数量，对于数量要求比较多的可以同厂家进行洽谈至不限数量使用，但价格相比固定数量的会略高一点。大致成本在100万-120万左右，除去物理硬件成本，该项支出占总成本的50%-60%左右。

1.3 定制化开发成本：对于厂家现成的云管平台，如果想要进行相应的流程开发或同自身的其它系统（诸如告警系统、流程系统、大屏展示系统等）进行对接，这就需要进行定制化开发，因此就需要一个定制化开发的成本。定制化开发的成本根据需要定制化开发的内容量来进行估算，大致成本是根据开发量按人月4万-5万来进行估算的，按开发量的大小来算该项支出占总成本的10%-20%左右。

1.4 维保服务成本：对于云管平台来说，出现问题则需要相应的维保服务来进行解决，因此对于银行来说，维保服务成本也是必须的，这样出现问题也能及时进行解决，维持云管平台的健康稳定。大多数情况下会赠送一年的免费维保，维保过期后需购买后续的维保服务，维保服务的大致成本为一年40万-50万，该项占总成本的15%-20%左右。

1.5 驻场服务成本：对于大型的云管平台的落地，仅靠维保服务是无法满足银行业的要求，这时云管平台厂家的驻场服务就成了一个可选项。以专业的驻场人员来全流程维护云管平台，负责云管平台的运营和运维。但对多数小型的云管平台项目来说，驻场服务是可有可无的。因为平台大多数时间都是稳定的，即使有问题通过维保服务也能及时解决。驻场服务的大致成本为一人一年40万-50万左右。

2、 采用开源的云管平台框架进行定制化开发；对于有技术研发能力的银行来说，通过开源的云管平台（诸如OpenStack等）为基础来定制化开发适合该行的云管平台。其中涉及的主要成本是开发人员的人工成本以及后期的维护成本，对银行的开发人员自身技术要求也比较高。对于这种自研自用的云管平台来说，因为涉及的面比较广，既有计算、存储、网络虚拟化等，其上又有云管等，投入的人员成本也会很高，后期的维护成本同样也会如此。

3、 自己研发云管平台，对于大多数银行来说，如果说技术积累不是很雄厚的话，是无法通过自身的技术力量去单独开发一个云管平台，其前期投入的成本也会很高，研发出来的产品性能或许和开源的云管平台产品不相上下，这就容易造成资源浪费，所以这里不再详细说明。

四、在银行云管平台项目中，如何进行技术路线的选择？

在云时代高速发展的推动下，对于传统银行如何进行云化变革，如何进行上云技术路线选型，依然存在不少的疑惑。云管平台选型方向不多，但随着不同银行对于云管平台要求实现涵盖范围的不同，其部署的难度、实现效果也不同，因此对于技术路线的选择显得很重要。

因此，根据自身云化业务规模建议选取业内比较成熟的技术框架，下面对具体技术路线的选型详细分类说明。

1、开源技术方面

随着云管技术多元化的发展和国产化趋势的推动，银行云管平台项目建设把目光转到开源技术架构。国内云管平台使用较多的技术框架是OpenStack，OpenStack是一个开源的云计算管理平台项目，由几个主要的组件组合起来完成具体工作。OpenStack支持几乎所有类型的云环境，项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。OpenStack通过各种互补的服务提供了基础的IaaS解决方案，每个服务提供API进行集成。OpenStack覆盖了网络、虚拟化、操作系统、服务器等各个方面，然而其不是一个产品，其在严格生产应用过程前必须经过优化，但OpenStack提供了一种优秀的IT模型和框架，银行业可以通过OpenStack量身定制私有云。

中国银联是金融行业最早介入云计算领域，通过数年云计算落地建设，打造出金融行业第一朵云。截至目前，基于OpenStack建设的私有云已经稳定运行1000多天，平台累计具备了11960vCPU、33280G内存和600TB企业级存储计算力，初步建成了包括云资源管理平台（IaaS）、云集成开发平台（PaaS）、智能支付终端平台（SaaS）等在内的云计算基础平台和应用平台。其它国有大行基于OpenStack的云平台如雨后春笋般全面铺开，但对于中小银行来说，自身科技力量比较薄弱，而基于OpenStack的云平台建设上需投入很大的人力和物力，因此基于此银行要根据自身的能力来量力而行。

2、联合开发

这种模式一方面可以更好的满足行内各种实际需求，另一方面可以充分利用厂商的专业技术能力，但这种研发没有固定模式可寻，建设周期相对较长，因此不太适合大部分银行进行云管平台部署。

3、产品购买

由于中小银行自身科技能力有限，因此偏向于市面上成熟化的云管平台产品，这种模式建设周期相对较短，在进行本行落地定制化的过程中有相应的应用案例参考，一般建设周期相对较短，定制研发多以落地为主，技能要求相对较低，选择时建议选择相对开放易于定制的产品。市面上大多数成熟化的云管平台都是基于OpenStack进行优化开发而成，因此技术路线也是基于OpenStack的。

因此在进行云管平台技术路线选择时，需要综合考虑平台的建设目标、投入成本、团队技术储备、所选技术路线的成熟度、生态圈发展情况及其未来发展趋势等多种因素。但市面上能选择的技术路线不多，主要是以OpenStack技术路线为主。

五、在银行云管平台项目中，如何进行云管产品的选型？

对于云管平台项目来说，云管产品的选型是整个项目中最重要的一环，因为云管平台选型的好坏关乎整个云管平台项目是否能满足当初制定的各项需求、能否满足功能要求、能否满足平台性能指标及能否满足平台安全可靠的要求等。此外云管平台项目还涉及底层物理环境、网络设备、虚拟化方式、SDN等产品的选型，但就云管产品来说是部署在这些产品之上的，直接向客户展示平台界面，客户从平台界面上能够直观的感受平台的各项功能展示，对平台的功能和性能都有很清晰的了解，因此云管产品的选型需格外重视。

由于云计算技术的快速发展，银保监“十三五”规划对于银行上云有了清晰的规划及银行自身业务的发展，这些使得银行业对于云管技术越来越感兴趣。对于银行业来说，云管产品的选型要贴合行内自身的需求，能实际解决行内存在的各种痛点问题。因此在产品的选型之前，需要理清行内对于云管产品的各项诉求，特别是要抓住一些核心诉求。

1、云管平台在银行信息化过程中有着独立的平台定位和使命。因为银行业自身业务的发展或早或晚都将面临着几个关键技术挑战，即资源服务化、资源全生命周期管理和异构管理及多云对接。这三个挑战共同需要一个独立的平台出现——即独立云管平台。

资源服务化：如果需要对银行内部各种资源进行服务化，那就需要一个独立的用户/租户体系，这个用户/租户体系需要超越现有资源自带的用户/租户体系。这就是独立云管平台一个重要的产品特征。但银行内部不同产品及能力在服务化支持能力上参差不齐，这就要求云管平台能够针对不同产品及能力的现状建立合适的资源服务化模式，而独立云管平台则可以保障这个模式得以灵活构建。

资源全生命周期管理：银行内部的资源形态多样化，有X86服务器、小机这样的传统设备，也有VMware虚拟化、KVM虚拟化等虚拟化设备，还有备份、监控、安全等运维相关系统。每种产品及能力因其定位不同，侧重的场景不同，其生命周期管理模式也不同。而云管平台需要能够提供足够的扩展能力，让不同资源的生命周期管理模式在其框架内实现。

异构管理及多云对接：银行内部的资源异构主要来自于两个方面，一是银行资源的演化和迭代是一个长期的过程，这就意味着不同阶段的产品会在长时间进行共存。最为典型的现象就是很多企业内部资源会同时存在有小型机、X86服务器、X86虚拟化等。因为这个原因，绑定一种产品及能力的云管平台很难承担起整个企业资源能力云化的使命。

2、云管平台在银行信息化转型过程中需要有独立的持续演化能力。由于云管平台的特殊定位，它一方面需要面向最终业务用户，另外一方面需要连接大量云服务。

针对以上银行对云管产品诉求的分析，结合银行自身的实际情况，对市面上主流的云管产品进行分析。由于云管平台项目涉及的东西较多，不光有云管产品，还有服务器、底层虚拟化技术、硬件SDN设备、网络设备、安全设备等。因此针对整个项目通盘进行考虑（这里服务器的耦合度不大，故可以排除在外），是将云管平台项目按以上模块进行拆分，各自选择厂商；还是选择一家技术能力较强，产品线全面的厂商。对于以上两个方向进行综合考虑，按模块拆分确实可以选择各模块水平排名靠前的厂商，但模块对接时需要各厂商进行相应的对接，这就需要对相应的厂商进行良好的沟通，相应接口的对接，问题排查的处理等。而一家厂商可以解决以上协调的问题，但又存在着该厂商的某个模块相比其它专门做这个模块的厂商存在技术的差别。基于全面通盘的考虑，可以考虑选择一家厂商来实施云管项目。

六、在银行云管平台项目中，涉及新购或扩容改造的产品、资源有哪些？

对于一个完整的云管平台项目来说，涉及的产品模块比较多，有服务器设备、网络设备、硬件SDN设备、云管平台产品等；此外如果还需个性的定制化，比如流程的开发、第三方系统的对接等，就需要有定制化开发服务；对于云管平台项目来说，还需要考虑平台的维保服务，以便有问题发生时及时介入处理；如果是属于大型的运营类云管平台，还需要有专门的驻场服务来负责整个平台的运营。下面是一份完整的服务采购清单。

七、在银行云管平台项目中，如何进行定量需求分析？需要收集哪些需求数据信息？

在云管项目中，需求分析是平台部署的先决条件，只有理清了平台的需求，才能更好地为后续建设服务。需求分析可分为问题识别、分析与综合、编制需求分析文档、需求评审等四个阶段，包括以下几个方面：确定平台所期望的用户类；获取每个用户的需求；了解实际用户任务和目标以及这些任务所支持的业务需求；分析用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息；将平台的需求划分子系统，并确定平台的功能和性能属性；讨论得出平台部署优先级；将所收集的用户需求编写成需求规格说明和模型；评审需求规格说明，确保与用户达成共识。

1、问题识别：首先理清云管平台项目为什么做，能不能做，值不值得做，做到什么程度。需求包括：功能、性能、环境、可靠性、安全性、保密性、监控、展示、用户界面、资源使用、成本、进度等。银行云管平台的建设，不仅需要为基于异构化设备提供运行和管控平台之外，还必须非常重视满足金融行业严苛的监管和安全要求。这样的定位决定了在银行建设云管平台除了要具备市场上大多数云管平台产品的能力，还需为银行的特殊监管需求进行定制。

2、分析与综合：以云管平台项目的数据流和业务流为出发点，逐步细化所有的平台功能，找出各模块之间的联系、接口特性和设计上的限制，分析它们是否满足功能要求和性能要求，综合成平台的整体解决方案，给出平台的详细逻辑架构和物理架构，主要的需求分析步骤如下：

（1）用户需求的目标分析；

通过前面的问题识别，明确云管平台项目要实现的功能；并根据用户提出的需求进行目标分析，建议考虑包括的方面有：云管平台统一纳管异构资源（X86 物理机、小型机、 虚拟机）；满足金融监管和安全要求；支持银行应用发布体系、高可用管理策略；对接底层异构资源池，遵从云计算资源的统一管理和分配；实现部分业务的动态扩展需求的场景；满足操作系统、应用、第三方功能服务化，提供标准API接口。实现多租户管理，各租户之间逻辑隔离；同时还需具备应用自动化、弹性扩容等高级特性来满足现有业务需求等。因此这里需要考虑的数据信息有：云管平台的整体规模大小、要实现的具体功能、定制化开发的内容要求、是否对接第三方系统等。

（2）逻辑架构图、物理架构图、网络架构图；

（3）云管平台设计；

在完成之前底层的逻辑、网络及物理架构设计之后，就到了云平台设计阶段，对于云管平台项目来说，云管平台的好坏关乎着整个项目的走向，因此对于云管平台的设计需要考虑如下信息：云管平台要实现的哪些功能、是否需要对接现有的第三方系统、是否需要部署监控系统、监控系统是否要同现有监控系统打通、是否要流程管理、流程管理涉及哪些业务流、流程过程中是否需要短信对接、平台虚机是要需要备份、要备份如何进行备份、备份的策略又是怎样、云管平台是否需要部署防病毒服务器、云管平台是否需要等保评级、上面的虚机是否也要进行等保、虚机是否需要进行计费、是否需要收费、是否要进行分租户的方式进行管理、租户之间是否需要隔离等。

（4）平台可用性指标；

根据用户要求，需要对云管平台高可靠性、兼容性、并发IOPS数、系统响应时间和可用性指标进行明确，并得到用户认同。因此需要收集如下信息：云管平台高可靠性是否要达到99.9%还是99.99%，上面的虚机是否兼容各个操作系统的版本、并发IOPS数是否满足用户需求、系统响应时间是否满足要求、可用性指标是否满足要求以及云管平台是否支持灾备或双活架构等。

3、编制需求分析文档

根据以上的分析与综合，梳理以上的需求数据信息进行整理归纳并按照相应的格式编制出需求分析文档。

4、需求评审

对整理好的需求分析文档提交给相应的管理部门召开相应的人员对云管平台的需求分析报告进行需求评审，确定需求是否合理，是否贴合实际情况，是否能带来很大便利等，从多方面进行综合考量。

八、如何规划银行云管平台项目的工程实施步骤？

对于一个完整的云管平台项目建设来说，主要分为:启动阶段、规划阶段、实施阶段及验收阶段。下面对这四个不同的阶段做详细的说明。

1、启动阶段：

•项目立项申请；

•组建项目组（任命项目经理及技术经理、确认项目成员）；

•收集项目信息；

•举行内部项目启动会；

•举行外部项目启动会。

2、规划阶段：

•制定并刷新《项目交付计划》；

•制定硬件互联方案（设备供电环境及安装位置确认、各设备功率计算、绘制设备机柜位置图、设备接口连线及条线长度数量确认）；

•制定《项目实施方案》；

•制定《项目测试方案》；

•各组件软件版本确认等。

3、实施阶段：

•服务器及网络设备到货：设备上架及加电、设备拉线及标签整理；服务器固件检查如不符合需要进行固件版本升级；服务器管理口配置。

•基础环境配置及调试：包括配置及调试管理网、业务网、存储网络、网络出口网络等。

•软件系统安装及部署：包括计算虚拟化软件安装、存储虚拟化软件安装、SDN控制器安装部署、云平台安装部署。

•软硬件联调及云管平台对接：包括多平台联调、多租户调试、审批流程调试及网络安全调试。

•云平台功能测试

•整体功能测试

•云平台性能测试

•定制化开发：包括需求阶段（需求调研、需求确认、需求评审、需求规格）、设计阶段（UI设计、交互设计、数据库设计、软件概要设计）、开发阶段（前端代码开发、后端代码开发、UT&IT、对接联调及系统测试）和部署上线及维护（软件部署、验收测试、上线前测试及软件试运行）这四个阶段。

4、验收阶段：

•验收材料汇编；

•项目验收测试；

•项目技术培训；

•项目试运行；

•验收文档签收。

对于整个云管平台的建设过程来说，存在的难点主要有：

1、沟通难点：由于项目相关参与方较多，可能因复杂关系及利益存在影响项目沟通效率；开发定制化涉及需求规格及软件设计的需求传递，需要双方及时沟通确认；云管平台与第三方系统对接的适配等。这些问题可能会给项目的进度和范围管理带来很大的麻烦，基于此问题，通过充分的干系人分析、调研及沟通，充分的需求调研等方式来加强沟通。

2、安全难点：对于要面向互联网业务的云管平台来说，是需要同外网进行交互的，就银行来说这就需要格外注重平台的安全性。因为安全防护的好坏关乎其上业务能否正常运行，如其上的业务动不动就被人攻击对整个平台来说是灾难性的。因此对于安全这个难点问题，经过充分考虑，建议建立一个专门的安全资源池（通过X86服务器进行部署），在上面部署防火墙、WAF、IPS等一系列市面上常用的安全防护软件，通过引流的形式将面向互联网业务的流量在安全资源池里进行清洗，充分保证业务的安全性。

九、如何解决银行云管平台项目中的监控整合难点问题？

对于银行业来说，云管平台项目建设完成之后就需要部署平台的监控软件，以便对云管平台现有资源进行监控。由于云管平台有自身的一套运维监控系统，但与企业原有的其它监控软件来说相对独立，无法整合。这就造成了一个中心两套监管系统的尴尬局面，运维人员不得不在两个监控界面上来回切换进行监控。原有的监控软件由于建设较早，覆盖面也比较广，涉及的系统也比较多，在一些功能上也所有优化；同时也关联着告警工单系统、短信提醒等多种措施。但由于新部署的云管系统监控软件相对于传统的监控软件来说相对独立，无法有效地生成告警事件单及短信提醒，造成告警事情处理不及时，影响平台的稳定性和可靠性，同时也可能造成业务故障影响。这也是对多家中心银行带来的痛点问题，因为对于银行来说，监控的范围要覆盖到每一套系统，绝不允许“灯下黑”的现象发生。

对于该问题的产生，主要是由于两套监控软件相对独立，传统的监控软件位于生产网段区，而云管平台监控软件位于带外管理区，两套网络逻辑隔离，互不相通。而要想实现传统监控软件相应的告警处理机制，这就要求云管平台监控软件也需要同工单系统、短信猫等系统也需要进行对接处理。要想实现两套监控软件的整合需要对接的系统较多，耗费的工作量也较大，对于部分中小银行来说仍维持现状，两套监控软件同时进行监控运维，但云管平台的监控软件监控力度有所薄弱。

基于两套监控软件并存的现状出发，我们分析解决该问题的几种思路：

一、重新部署一套新的监控软件，能够整合传统的监控软件和云管平台监控软件，由于两套系统部署在两个网络隔离的网段中，重新部署需要面临着网络的问题，同时重新部署需要耗费大量的人力和财力去采购新的监控软件，去整合现有的各种监控指标，这不亚于对现有的监控进行推倒重来，故此想法可行性不大。

二、将某一套监控软件整合到另一套监控软件中，形成一个统一的监控系统。由于传统的监控软件运行多年，对接的工单、短信系统也已经使用多年，故将云管平台监控软件整合到传统的监控软件中工作量相比就少很多。同样基于整合便捷的考虑，也不必让云管平台监控软件去对接其它第三方系统，利用传统监控软件对接第三方系统成熟的便利性就传统监控软件进行接口打通，将云管平台监控软件告警推送至传统监控软件上，利用传统监控软件来生产工单及短信告警。这就极大节省工作量，只需将告警信息推送至传统监控上即可。

针对以上思路的综合考虑，决定采用第2种方法来进行监控整合。

1、将传统监控软件对接的API接口提取出来发给云管平台监控软件方人员，尤其对告警信息接口对接，进行告警信息的推送。

2、由于两套监控软件网段逻辑隔离，部署一台虚机配置两块网卡，分别与两套网段进行相通，起到跳板机的作用，解决网络隔离的问题，并在跳板机上部署相应的推送程序。

3、将云管平台监控软件上的告警信息通过跳板机推送到传统监控软件上，在传统监控软件上进行告警显示，工单生成及短信提醒等后续告警手段。

通过以上方式将云管平台监控软件的告警信息推送整合到传统监控软件上，使运维人员可以在传统监控软件上直观地查看两套监控软件的告警信息，及时有效地处理各类告警信息，避免监控的死角及“灯下黑”。做到监控有的放矢，保障系统稳定可靠。

十、在银行云管平台项目中，SDN模块如何进行设计？

SDN即软件定义网络，是一种网络设计理念，只要网络硬件可以集中式软件管理，可编程化，控制转发层面分开，则可以认为这个网络是一个SDN网络。所以说，SDN并不是一个具体的技术，不是一个具体的协议，而是一个思想、一个框架。它具有控制平面与转发平面分离、控制平面集中化及网络可编程这三个特征。就银行的云管平台项目而言，由于金融行业强调安全可控及便捷管理，因此一个好的网络管理模块对于云平台的重要性来说不言而喻。而SDN模块在云平台网络管理主要体现在：一是自动化；二是多租户需求；三是通过SDN的方式能够把PaaS进行隔离，从而能够更好的进行使用，另外还有访问方面的一些需求。SDN网络架构的改变是银行业最难啃的一块骨头，而在最难啃的骨头中我们又会涉及到异构的管理，和新旧的管理。

SDN的设计理念是将网络的控制面与数据转发面进行分离，并实现可编程化控制。SDN的典型架构共分三层，最上层为应用层，包括各种不同的业务和应用；中间的控制层主要负责处理数据平面资源的编排，维护网络拓扑、状态信息等；最底层的基础设施层负责基于流表的数据处理、转发和状态收集。

从传统的网络设备（路由器，交换机）的设计上看，它由软件控制和硬件数据通道组成。软件控制包括管理(CLI,SNMP)以及路由协议(OSPF,ISIS,BGP)等。数据通道包括针对每个包的查询、交换和缓存。此时如果将网络中所有的网络设备视为被管理的资源，那么参考操作系统的原理，可以抽象出一个网络操作系统的概念，这个网络操作系统一方面抽象了底层网络设备的具体细节，同时还为上层应用提供了统一的管理视图和编程接口。这样，基于网络操作系统这个平台，用户可以开发各种应用程序，通过软件来定义逻辑上的网络拓扑，以满足对网络资源的不同需求，而无需关心底层网络的物理拓扑结构。

SDN本质上具有“控制和转发分离”、“设备资源虚拟化”和“通用硬件及软件可编程”三大特性，这带来了一系列的好处。

1、设备硬件归一化，硬件只关注转发和存储能力，与业务特性解耦，可以采用相对廉价的商用的架构来实现。

2、网络的智能性全部由软件实现，网络设备的种类及功能由软件配置而定，对网络的操作控制和运行由服务器作为网络操作系统（NOS）来完成。

3、对业务响应相对更快，可以定制各种网络参数，如路由、安全、策略、QoS、流量工程等，并实时配置到网络中，开通具体业务的时间将缩短。

基于以上考虑，对于银行云管平台项目而言，要想实现网络自动化及多租户的需求，SDN对于云管平台来说是不可或缺的。因此就银行对云平台的SDN模块选型来说，主要是以银行自身情况为出发点，综合考虑银行自身的管理协调、技术力量、人员配备、平台架构及网络架构等，从而决定是否采用商业的解决方案还是开源的解决方案。两种方案考虑如下：

1、 开源解决方案，如引入OVS降低了使用成本、提升了网络灵活性。但这种原生的SDN方案存在诸多不足：和不同厂商对接上存在很多的技术间隙、缺乏对网络资源的统一灵活编排、缺乏分级的网络资源管理能力以及对网络设备的管理及存在定制化差异等。对于开源方案来说大多只是简单的SDN应用，想要契合自身业务，必不可少需要进行二次开发，且还要建立在有人才支撑的前提下，否则只有引入商业方案。

2、 对于商业的解决方案来说，总结业界云管平台SDN方案从实现方式上可以分为两大类：基于软件Overlay方案、基于硬件Overlay方案。软件的Overlay方案主要是VMware的NSX方案；硬件Overlay方案的厂商以华为、华三及思科这三家的产品为主。结合云管平台自身网络设计为出发点进行考虑选择硬件Overlay方案，并结合云管平台方案的选型来综合考虑这三家硬件厂商的SDN方案，确保SDN与云管平台一致性和兼容性，并在选型的过程中考虑价格、功能和性能等因素。

十一、如何在银行云管平台项目上线后对运维工作进行管理安排？

就银行业来说，一个云管平台项目的建设过程时间并不长（小的1个月之内，大的2到3个月），建设完成之后就面临着平台的运维工作，大点的云管平台还存在着运营工作，两者功能大都类似，但又不尽相同；一个偏向于保障，一个偏向于经营；而运维是运营的基础，只有做好了运维，才能更好的为运营服务。因此这里着重介绍下云管平台上线后的运维工作。

1、运维制度的建立：

对于银行业来说，良好的制度是保障业务稳定运行的前提，也是业务流程标准化的硬性规定。因此对于云管平台项目的运维工作来说，制定先行才能确保运维工作顺利有序进行。在此我们制定了《云管平台日常巡检规范》、《云管平台故障处置条例》、《云管平台业务申请流程》、《云管平台业务上线规范》、《云管平台业务下线流程》、《云管平台安全管理规范》、《云管平台日常巡检指导书》等一系列制度。

2、运维人员的配置：

运维人员的配置是保障运维工作顺利开展的基础，只有打好了基础才能确保工作的顺利实施。因此就云管平台来说对于运维人员的考虑，也需充分考虑银行现有的运维力量；对于大多数中心银行来说，运维人员比较有限，如果配置专门的云平台运维人员对于银行的经济和人力成本来说压力较大，大的银行对大型的云平台可以考虑配置专门的运维组织架构和人员。因此就大部分如何利用现有运维人员来对云管平台进行运维是必须要考虑的问题。由于现有运维人员对于其它系统的运维工作已经轻车熟路，业务也比较熟悉，因此可考虑在日常的运维工作中加入云管平台监控这一块到日常的巡检工作中去，人员可以复用原来的运维人员。

3、运维任务的确定：

运维体系设计：主要包括云平台基础架构标准制定和执行、业务迁移规划及管理。

运维日常流程：主要包括监控并维护云环境的稳定运行、云环境中系统及应用的日常操作、机房环境及基础架构监控和维护；并按照《云管平台日常巡检指导书》的要求填写每日的《云管平台巡检日报》。

运维故障管理：主要包括日常告警的监控及处理及计划的灾备演练等。

运维变更管理：主要包括业务上线及下线的处理，业务方日常的工单处理。

运维容量规划：对于云管平台容量进行日常监控，一旦发现容量阀值超过预警，及时规划及扩容新的资源，确保云平台的稳定可靠。

4、云管平台的培训：

培训工作是在运维介入之前就必须要开展起来，让相应的运维人员了解整个云管平台的相关知识。对此就云管平台的产品、业务流程、架构流程、告警查看、问题反馈处理等方面进行专门的培训，让运维人员充分了解平台的细节内容。

以上对云管平台的运维工作做了简要的介绍，但其中的也存在着云管平台告警监控的难点问题：由于云管平台有一套自身的监控软件，而传统的系统也有一套监控软件，这对运维人员来说，需要在这2套软件之间来回进行切换，而传统的监控软件对于银行来说确是十分重要，这就会导致云管平台监控的间隙问题。因此可以通过接口对接的方式就云管平台的监控告警推送至传统监控软件上，用一套系统分别对传统及云管平台进行监控，覆盖面拓深，消除监控间隙。

 资料/文章推荐：

• 中小银行如何通过云管平台实现Power和x86资源自动化管理

  http://www.talkwithtrend.com/Document/detail/tid/422605

• 金融行业云管平台架构方案设计参考手册

  http://www.talkwithtrend.com/Document/detail/tid/40759

http://www.talkwithtrend.com/Topic/108193

下载 twt 社区客户端 APP

或到应用商店搜索“twt”