江苏农信金融云建设“20问”：银行私有云建设思考与实践

当前，金融领域已经成为应用云计算技术最迫切的行业之一。随着大量的金融机构开始依托云来承载应用和处理高并发业务，云计算技术正在与金融行业快速结合，在金融行业内快速发展。 2020 年是 “ 十三五 ” 收官之年，也是 “ 十四五 ” 编制之年，“新基建”推动之下， “ 十四五 ” 如何通过云计算新型基础设施建设持续深化金融供给侧结构性改革成为重点。

江苏省农村信用社联合社（以下简称 “ 江苏农信 ” ）作为江苏地区规模最大的金融机构，在一行两会的指导和要求之下，为持续做好线上线下泛金融服务一体化建设，打造服务 “ 三农 ” 的信息系统支撑平台，在 3 年时间内构建了大规模农信云平台，同时，建成了覆盖全省 62 家二级法人农商行的金融行业云平台，为农信行业树立了开源云计算探索的标杆。

银行建设私有云能给业务带来哪些好处，江苏农信是怎样依靠技术促进业务的发展的呢？江苏农信云平台团队负责人对网友关注的问题进行了解答。

Q ：中小银行建设行业云会遇到哪些困难？除了江苏农信下的农商行，还有其他农商行应用江苏农信的农信云平台吗？

A ：目前中小银行建设行业云其实并不是刚需，更多时候，中小银行是使用行业云的最大群体。建设行业云需要较大的资金和技术投入，且后期面临很高的运维、运营压力及金融机构客户获客成本压力。

农信行业天然的二级法人的架构及省联社对农商行的指导和服务角色，比较适合建设行业云，并先从省内开始提供服务逐步扩大到省外和行业。

建设行业云的困难主要就是技术力量在不断扩大的行业云规模面前逐渐捉襟见肘，需要持续吸收新的技术和人才，并高效选型后落地到行业云当中。另外，需要时刻明确总体建设目标和阶段性建设重点，做好建设规划并遵循规划进行建设，稳中求进，实事求是，因为各个厂商推荐的解决方案和产品真的太多了，容易步子迈的特别大，但是效果达不到建设预期。

建设行业云的目标其实是整合集约、持续创新、真正服务省联社自身的同时更要服务好农商行的信息科技建设，做到行业标杆。

目前江苏农信行业云还是立足江苏省内农商行，暂时没有进行省外拓展。

Q: 江苏农信平台是否经过了网络安全等保测评，有哪些需要改善的地方；建设过程当中，在网络（信息）安全等级保护方面，有哪些主要的规划和实施工作？

A ：我们有单独的安全团队对各类业务系统和基础架构进行安全建设的把关，云平台的建设也是依照等保 2.0 的要求进行了安全自检及加固，且会持续进行加固和优化。如安全管理中心、安全区域边界、安全通信网络、安全计算环境、以及安全物理环境等，云平台本身在建设过程中就严格按照网络隔离和安全规范在进行设计。

Q ： 江苏农信的云平台有提供数据库服务和大数据服务吗？

A ：目前江苏农信有金融级分布式数据库，传统的 DB2 ORACLE 等，还是在原有团队进行维护。云平台主要是支持的分布式数据库，缓存数据库等。

大数据目前不是云平台厂商来提供，我们有几个合作伙伴的产品经过选型后在进行使用，但是 hadoop 的运维也在云平台团队。

术业有专攻，建设云平台其实最重要的就是专业的人做专业地事，找厂商的时候还是要看到他们最专业的地方，没必要强求一家全部搞定，也不现实。

Q: 江苏农信在 IaaS 层做的很多，都是为法人行社做的。我们甘肃都是集中在省联社的。请问一下有没有对我们这种情况有什么建议。

A ：如果是咱们已经集中在一起，其实比较重要的是“私有云”的建设，私有云本身不强制需要云管平台 。另外，甘肃这边现有的 IaaS 技术架构不知道是什么技术，如果是 vmware 的话，可以考虑引入另外一种虚拟化技术，或者云平台，形成异构环境，毕竟国产化是较大的趋势，且建设性价比也有优势。

Q: 以江苏农信私有云为例，咱这边有互联网资源池、生产资源池和开发测试资源池。

A ：是的，私有云和行业云都分别建设了 3 朵不同业务类型的云平台以满足隔离需求，云平台的控制平面整体资源占用比较轻量，所以我们就索性做了完全隔离，但是在云管上做了统一管理。

Q: 请教互联网云的运维是否必要进行二十四小时人为监控，互联网云的网络安全该如何加强，比如虚拟机逃逸漏洞该如何防范？

A ：互联网云这边我们是自己建设了监控体系，并进行了运维开发，当然了，如 zabbix 、 ELK 等开源工具大家也都在使用，然后我们的运维开发团队也做了一个针对云平台的 CMDB ，用于按照自己的监控侧重点和各类基线进行状态监控。云平台本身的监控基本可以满足日常需求。

告警是对接了行内的 Tivoli 平台， ECC 这边我们会安排人员值班制，有告警也可以统一通知，值班人员也不需要特别了解各系统的技术原理。

虚拟机逃逸漏洞在私有云这边没遇到， vmawre 这边反而有，关于内核的漏洞，我们肯定要求厂商第一时间进行修复，这也是他们的职责所在。

Q: 请问这三个资源池中互联网资源池和生产资源池 对比开发测试资源是否物理隔离，相当于三朵云

A ：全部物理隔离的，物理上三朵云，云管上一朵云不同资源池而已。

Q: 大容量如 6T 左右生产应用在云平台上如何实现？

A ：云硬盘支持单个硬盘 64TB ，可以直接创建云硬盘并挂载使用。另外， 6TB 的生产应用，不太清楚是不是数据分布机制有调优和优化的可能性。

Q: 三朵云，计算资源池、存储资源池都是专属使用？

A ：是专属使用的。

Q: 江苏农信云团队 7 个人，具体职责是什么？自主可控的水平怎么样？

A ：计算、存储、云管等方向分别有专人主要负责牵头，工作内容包括建设以及与厂商驻场人员和 PM 对接，还有专门的人员牵头进行应用商店、 PaaS 平台、运维开发等工作的推进。由于云平台整个产品化程度比较高，平台本身的运维工作并不复杂，自主可控水平相对较高。大家对于 opesntack 、 ceph 、 linux 、 kubernetes 的了解也在逐渐深入，每个厂商我们都有对应 1-2 人的原厂驻场。技术人员我们也进行了小范围的的社招补充，这也比较有必要。

Q: 请教两个问题： 1 、对于云平台上， IaaS 和 PaaS 在运维上有界限区分么？是分不同的团队运维还是一个团队运维？ 2 、云平台上的应用开发框架，比如微服务框架，这块我们有技术路线选择么？是选定一种还是会多种技术框架并存？

A ：目前我们的 paas 这块的运维由于规模不大，所以暂时都是和 iaas 团队共同运维。后续 paas 规模大起来后，会依据实际情况再做考虑。

开发框架目前主要是 sprincloud 比较多，不建议超过 2 种，最好一种，否则整体技术的自主可控会很复杂。

另外，互联网公司的相关框架私有性比较高，容易造成 2 年后别人无法接手的局面，所以要相对慎重选择，不过长久合作的话，类似 TSF ， SOFA ， EDAS 也可以选择。

Q: 请问江苏省联社现在是 7 个人专职负责云平台运维吗？和传统运维有分离吗？

A ：有分离的。

Q: 贵公司云平台建设是用的哪家技术？贵公司是基于什么样需求建设的云平台？遇到那些不好解决的问题。

A ：云平台是使用的易捷行云的产品。

一是提升资源利用率，降低计算设备成本。省联社目前使用大量中低端服务器，虽已大部分实现计算虚拟化，但缺乏统一资源调度平台，无法灵活实施调度策略，因此大量计算资源处于较低利用率状态（低于 20% ），不仅导致计算设备投入的浪费，也造成机房空间和电力浪费。通过云计算技术可提升资源调度效率，提高计算资源利用率，降低成本投入。

二是改变存储方式，降低存储设备成本。省联社目前数据存储以集中存储为主，存在设备价格高昂和扩容困难等问题。目前省联社即将开展集中数据作业中心和大数据平台等项目，可以预见在近期省联社数据将出现爆发增长态势（预计增长超过 50% ）。通过运用云计算技术，将改变传统存储方式，存储扩容将更为方便，存储价格将大幅度降低。

三是提高管理效率，降低运维人员成本。随着全省农商行业务种类和业务规模的快速发展，省联社信息系统硬件数量出现急速增长（计算设备增长 150% ，存储设备增长 50% ），运维工作量直线上升，运维人员数量缺口也在不断加大。通过云计算平台可实现计算、存储和网络资源的集中管理，将大大提升运维工作效率，降低人力成本。

在全省云平台规划的调研制定过程中，已有农商行向信息科技部提出将他们的基础 IT 环境迁移至省联社的共享云平台中的意愿。农商行普遍科技人员较少，但需要管理整个行的 IT 资源，包括机房基础环境和设备、各类外设硬件、自建的应用系统等，工作对象复杂，工作压力较大。农商行期望通过将 IT 基础环境迁移至省联社的共享云平台，降低自身工作的复杂度和压力，而且使用省联社的共享云平台可以规避使用其他公有云或行业云的数据安全问题。

Q: 请问江苏农信云平台有没有提供小型机？

A ：没有提供，云平台建设本身就是一个逐步去 IOE 的过程，现在原则上已经不再购买小型机等专用计算设备了。

Q: 请问江苏农信云计算团队的人员构成？云计算团队成立之初需要哪些专业技术、特长的人员参与建设？

A ：我们在建设和选型的时候，只有 3 个人，现在也就只有 7 个人。我们 7 个人运维了近万台 openstack 云主机，还有上千台 vmware 云主机，还有云管平台，还有部分 hadoop 平台，所以产品化要求就很高。

专业技术和特长的话，其实主要还是看建设规划，在 IaaS 和云管的建设过程中，一般系统组一名，存储组一名，网络组一名在初期是够的，关键是这些同事需要有做好横向技能拓展的心理准备，因为在云平台的架构下，运维的内容可能要横跨计算存储网络基础软件容器甚至监控等，要具备较强的学习能力和个人提升的期望。

Q: 江苏农信在构建“ x86+non-x86 ”混合资源池方面近期有什么计划？

A ：近期我们在考虑国产 x86 和 ARM 的混合资源池等搭建，主要还是希望能够跟上国产化的趋势和相关要求，云平台这边，采用的还是易捷行云的产品，兼容性会好一些，毕竟现在 ARM 和国产 x86 后续发展如何，还需要一些时间才能形成标准，所以小规模的通用性好的兼容性好的产品是比较重要的，涉及的业务改造评估还没进行。

Q: 各业务系统迁移到私有云平台，是否需要进行全面的业务回归测试？如果测试，发现的问题由谁来修改解决？

A ：目前迁移的过程中，并没有太多的迁移本身的问题出现，因为云平台提供的 iaas ，操作系统，基础软件和原有的 vmware 或者 x86 物理机没什么大的区别。发现的问题这一块就需要具体问题具体分析，如果是基础架构的问题，需要云平台厂商针对应用运行环境进行适配提供对应操作系统和各类资源，适配不了的话其实应当在迁移评估的时候就做好预警。

Q: 云上应用数据备份方面的能介绍下吗？

A ：目前我们除了云平台自带的云主机维度的备份外，更多的是使用了 TSM 在云主机装 agent 来备份文件系统，并且把备份服务在云管上做了自服务的二次开发。

Q: 请问容器化部署的过程中都采取了哪些安全控制措施？

A ：安全措施目前我们都是沿用的商业版 openshift 解决方案所推荐的安全 feature 。

Q: 江苏农信选择什么样的灾备架构，是两地三中心还是多中心，这个是一开始就考虑了吗？还是扩容的？

A ：目前针对云平台是同城的多中心（ 3 中心），是一开始就进行考虑的，建设的话，是去年下半年开始的。

Q: 我们江苏农信云平台的 IaaS 和 PaaS 是分开采用两家公司还是一体化采用一家公司的？

A ：两家公司的产品。 IaaS 采用的易捷行云，初期 19 家交流厂商和测试过程中，易捷行云分数是最高的，另外，给我留下深刻印象的是他们后台技术人员整体解决问题的速度、服务态度和工作热情比较好，前端团队也很专业和团结，这是一个很好 partner 的形象。

Q: 请问，江苏农信在行业云的基础上，是否考虑生态云建设，对外开放？

A ：会考虑的，且从一开始我们就在做相关的规划，现在已经初见成效。

我们大致是四步走，目前在第二步：

第一步选型和搭建基础平台：江苏农信是通过某个供应商 saas 解决方案来解决应用中心的问题，先搭建平台熟悉平台的使用，时间约半年，目前已经完成；

第二步，分别挑选试点服务进行上线测试，分别是 api 类服务：签 签、加 * 密平台；以及 app 类服务： 脱敏，目前建设处于这个阶段；

第三步：将之前的 DNS 服务、堡垒机服务等，也考虑进行在应用商店的发布；

第四步：开放生态（农商行可以上传应用并发布、认证后的应用厂商可以上传并发布、省联社可以上传），增加业务数量，并成立运营 team ，统一审核、运维和运营目前都是省联社在主导，人数并不多，处于前期阶段还没全面铺开。

Q: ARM 服务器现在做虚拟化，可以支持哪些操作系统和数据库？

A ：这一块我们才刚开始，目前知道的是，易捷行云产品支持：中标麒麟 V4/V10 、银河麒麟 V7 等、深度、 UOS 、 CentOS for ARM 、 Ubuntu for ARM 等，基本是能够满足业务运行需要的， windows 还是建议走国产化 x86 ，但是也听说了 windows for arm 还没时间详细研究。

Q: 容器化能支持数据库 RAC 吗？

A ： RAC 作为支撑核心应用高可用的手段，行方应该是花了很高的建设费用，所以对其期望一定是高可用，高性能，高稳定，能充分发挥 RAC 功能设计的全部能力。

所以 RAC 一般都是在物理服务器 + 共享存储的场景下进行使用，且心跳和存储性能及共享性要求都比较高。

则一般不建议进行虚拟化部署，更无法进行容器化部署了，但是从功能上来说，易捷行云的云平台是支持数据库的 RAC 以虚拟机方式部署的。

Q: 有没有对国密算法改造的案例介绍？

A ：易捷行云软件产品主要是和基础架构相关的解决方案，业务系统的改造是和合作伙伴一同进行，比如和 CEC 的中软一起做的某国有银行的 OA 国有化改造案例。

Q: 因为我们现在看到的微服务厂商的技术架构并不相同，新的产品几乎都采用微服务架构进行开发，所以这类的微服务产品如何能在容器云级别进行统一管理是我们比较关心的。因为如果微服务化后没法管理是比较头疼的。

A ：目前微服务厂商的架构有开源的 SprinCloud ， dubbo 系， gRPC ，如文思海辉、科蓝等；还有互联网厂商的 SOFA 、 TSF 等，确实很多。

这一点上，首先确定行内的开发架构是非常重要的，也直接决定了合作伙伴的选择，建议控制在 2 种以内，且至少包含一种开源框架如 SprinCloud ，然后和合作伙伴一起，逐步指定开发规范和改造规范，一般是开发部门、业务部门牵头，基础架构部门配合并做基础平台的建设牵头。

然后， IT 部门还是要统一进行基础平台的建设，并反向约束后续的业务系统开发，如统一建设基于 k8s+docker 的容器平台，建设 sprincloud 为主的微服务治理框架，这样业务厂商就需要按照咱们的既有规范进行镜像提供和业务改造即可，所以定规矩比较重要，工作要做在前，平台也要建在前。

Q: 贵司有没有其他的合作资源。例如三方资源、能力、流量等引入？

A ：资源有的，需要按照客户实际需求选择合作伙伴共同降低客户的获客成本，促进创新。