一、项目背景、目标及相关规划、实施

（一）项目背景

目前湖北省联社已建成“楚天农商云”和“互联网业务平台”两朵云平台，为全省农商行提供了更加灵活、稳定、安全、可靠的技术服务保障。随着业务快速发展，湖北农信的数字化转型已迈入重要阶段，每年互联网金融产品和业务种类持续增加，更新迭代速度日益加快，各地市行对于云平台的使用需求也逐步提高。当前全省农商行互联网金融业务发展面临如下难点： 

1.多层级法人体系独立运营。客户量大面广，需求差异大，个性化需求突出。 

2.业务适配上线周期长。各市县农商银行的互联网金融业务多部署在传统 IT 环境，应用上云需进行适配测试才可上线。测试周期长，适配工作重复，导致应用上线不及时。 

3.缺乏统一应用上云规范。各市县农商银行的应用软件及重点业务系统各不相同，各分支行技术能力不均衡，应用上云没有统一规范，导致人力成本时间成本上升。

4.运维难度大成本高。运维资源集中在省会发达地区，造成各市县运维人员水平良莠不齐，维护困难。

（二）项目目标

为有效应对以上挑战，满足农信体系银行业信息化建设的需求，湖北省农信社内部决定制定“多云运维体系”建设规范。该规范旨在为我行两朵云提供相应的制度规范，帮助省市支行实现业务全面发展、应用高效适配、上云统一规范、运维更加可靠。

（三）项目规划

本项目主要分为： 

1. 完善XC基础平台架构规范 

自2021年起，省联社依序投产了“楚天农商云”和“互联网业务平台”。为满足云架构建设要求，结合XC工作，拟定了《应用上云技术标准规范》等体系要求，旨在确保后期项目开发科学规范、系统维护稳定高效。

一是确立上云原则。所有新建项目遵循“统一标准、主动适配、能上尽上”的原则，强化技术架构规范，充分发挥云化服务能力，实现用更少的成本保障更多的业务系统稳定运行。

二是收敛技术路线。以省联社现用芯片、服务器、操作系统、数据库、中间件等业界领先XC产品作为基准，收敛技术线路，降低管理复杂度，依托“两朵云”架构，全面采用XC技术。

三是制定技术规范。为确保应用系统上云的准入标准，在设计规范、信息安全、高可用性、可拓展性、监控指标、日志记录等各项重要且基本的指标上均明确要求，从源头上保障系统科学性。 

2. 提高XC运维支持保障能力 

XC技术和产品目前处于起步阶段，整体市场占有率较低，技术成熟度不高，且缺乏完善的配套工具，导致运维管理难度较大。数据中心加强各项运维管理举措，提高自主可控能力。

一是确保运营稳定。安全生产是基础，结合今年XC任务需求，统筹规划资源扩增。严格按照全面XC产品线路和云平台技术标准，对“两朵云”进行XC资源扩容，确保系统资源充足，以满足日益增长的业务需求。

二是建立统一运维标准。结合ISO20000管理体系，逐步建立起云平台、网络安全、操作系统、数据库和中间件等8类XC产品的操作规范、安全基线、应急手册等运维标准。

三是完善运维体系。构建“以行内人员为主体，原厂商与集成商为支持”的运维团队保障体系；构建以“现场服务+远程支持”、“人员投入+备件保障”等多种方式融合的XC产品保障体系。 

四是加强运维人员培养。通过实操演练、原厂培训、外部认证等多种方式，加快行内技术人员培养。

（四）项目实施

湖北省联社已建成“楚天农商云”及“互联网业务平台”两朵云。本次“多云运维体系”建设规范由数据中心牵头负责实施，采用试点实施和推广的分阶段方式。主要经历了分为两个部分： 

1.应用上云

(1)上云原则

原则一：全省农商行共同使用的新建业务系统均要求上云，如果新建应用的技术栈无法与云平台适配，开发主管部门选择不上云，需经技术专家评审后报信息科技委员会通过。

原则二：全省农商行共同使用的存量业务系统更换底层基础设施或进行应用迁移/改造，按照“能上尽上”原则进行综合评估，如果开发主管部门选择不上云，需经技术专家评审后报信息科技委员会通过。

原则三：上云应用的架构和资源选型需满足云平台技术栈和应用设计要求，需适配云平台技术栈，并选择云化服务产品。

(2)上云流程

在应用是否上云及如何上云的决策中，涉及到业务发展、技术能力、成本收益、网络安全等多个方面，要根据“两朵云”服务范围，以满足云平台技术路线为前提，结合应用系统承载的业务类型，来综合考量，整体过程如下：

(3)准入条件

云平台采用开放性架构体系，能够兼容业界通用的设备及主流的操作系统、数据库、中间件等，基本上所有的应用系统均能达到上云条件。少数非准入情况说明如下：分为绝对条件（单下划线）和相对条件（双下划线 ）

(a)绝对条件出现，不能上云；

(b)相对条件出现任意1条，可向厂商求证；

(4)云平台技术栈 

目前，云计算技术在金融业普遍应用，技术栈范围覆盖面广。结合省联社目前已有技术栈和业界先进技术路线，以收敛原则为抓手，以专业技术为标准，确定我行云平台技术栈标准，以降低在技术选型、软件升级、问题排查、代码维护上的成本，助力应用快速迭代、提升开发运维效能，增强系统先进性与稳定性，实现用更少的成本保障更多的业务系统稳定运行。

云平台目前支持的技术栈列表如下：

“云平台”技术栈

(5)应用设计要求

① 安全要求

a．应用应明确需通过的等保认证等级要求。

b．应用应在其整个生命周期内考虑安全性问题，考虑范围包括：身份验证、访问控制、权限控制、数据安全、安全审计、应用层防护等。

c．应用系统在上线前，需进行应用黑盒安全测试，存在重大安全漏洞的应用系统不允许上线。

d．应用在云上对外仅能发布业务端口及服务，不得将管理控制台对外发布，不得将敏感信息（如配置文件）存放在发布目录。

e．对于应用的各类系统组件，需要进行安全配置与加固，避免高危漏洞暴露或弱口令等配置问题。同时须关注新版本或紧急补丁发布情况，及时制定升级计划。

f．对于通过互联网发布的WEB类应用，需使用WAF进行安全防护，同时所有服务器安装主机安全组件。

g. 等保三级及以上系统需配置使用数据库审计。

h. 应用系统内各种密码应符合密码复杂度要求，并在不影响业务的情况下定期更换。

i．应用系统的日志应保存6个月以上，日志中不得出现敏感信息。

② 高可靠要求

a．应用需明确高可靠需求，包括RTO、RPO要求。

b．云平台目前支持双活，单中心两种部署模式，各类云服务分为Region及AZ级可靠性，应用需根据需求结合云服务类型进行相应的云上架构设计。

c．对于需要进行双中心部署的云服务，可靠性为AZ级别的服务，需在两个中心分别部署实例：如虚拟机、NAT64、云加密机；可靠性为Region级别的服务，其实例需要分布在两个AZ。

d．对于需要双中心部署的非服务化云组件，单副本组件需要在两个中心分别部署实例；一主一备或多副本架构组件需要确保相应实例部署在两个AZ。

e．对于虚拟机、数据库需设定合适的备份策略，并定期进行备份恢复测试。

f．对于存放在云内文件存储、对象存储的重要数据，需额外考虑备份模式。

③ 可扩展要求

a．应用架构需要满足弹性扩容，弹性扩容应对业务尽可能无影响。

b．应用应优先支持横向多节点弹性扩容，且系统性能与横向节点数量应呈现线性关联，确保横向扩展性能可预期。

c．应用架构不同层级间应实现松耦合，当某层节点主机数量添加或者减少时其他层级应能自适应，实现快速的性能扩容。

d．云平台服务化数据库实例（UPSQL）支持通过增加CPU/MEM配置进行性能垂直扩容，并支持配置只读账号进行数据库读写分离。应用应充分利用此特性。

e．当单库无法满足应用需求，需采用分库分表技术。

④ 监控要求

a．系统在云上部署后需纳入监控。

b．云服务由云平台提供相应的监控服务。

c．非服务化云组件需额外考虑监控规划，包括但不限于各类数据库、中间件。

d．应用需考虑自身监控如何实现，并进行部署实施。

⑤ 日志要求

a．日志应异步输出，且磁盘故障不应影响业务的正常处理，应用系统不能因日志输出模块错误而影响运行。

b．任何级别的系统日志中不允许出现客户相关的敏感信息。

c．应用系统日志至少分为两类：交易日志和运行日志，且必须独立，分开存放。交易日志要满足附件《应用日志规范》中的调用链日志规范要求。

d．日志内容总体规则：应用程序日志原则上使用UTF-8字符编码，以便于将来的日志文件分析；不应使用系统输出进行日志记录；日志在记录时无论成功与否,都不应改变业务逻辑。

e．日志清理归档机制：应用程序必须实现定期清理和归档日志空间的功能；清理/归档规则(清理方式、清理周期、过期/清除策略等)要经过应用架构审查，且包含在安装指导手册中。

f．日志回滚机制：日志需满足按大小和时间的回滚策略，大小原则上不能超过1G，时间切分按天；日志数量应设置上限，防止出现日志数量过多，导致磁盘空间不足的情况；不允许采用同一文件覆盖的方式输出日志。

g．日志等级划分：

h．日志丰富程度级别、日志命名及存储规范、交易日志规范、调用链日志规范等请参考附件《应用日志规范》。2.运维运营保障 

（1）运维架构搭建

我行目前设立了云平台相应维护岗位，设置独立云平台运维团队。运维团队根据云平台特性和运维目标，分为平台运维、安全运维、网络运维、应用运维和流程质控五个小组。各工作小组将工作细化并落实各自职责。

（2）运维监控管理

运维监控侧，部署5台应用监控节点，专用于云平台业务系统的监控。此外运维人员组成专门的运行监控组，组内人员实时监控云平台上的所有应用，以确保应用安全性、可用性以及可靠性。

（3）运维工具使用

运维工具侧，使用专业的日志分析工具以及业务层网络流量监控工具，实时监控云平台整体应用运行情况。监控层面包括但不限于某个具体应用的性能监控、应用的日志、网络流量分析、网络流量监控等，以确保运维人员在有限的时间完成对云平台所有应用以及网络的监控，从而大幅提高运维人员的工作效率。

（4）运维人员培养

在传统存量和云平台的系统运维中，从多方面进行统一管理和规范，包括组织架构管理、运维流程规范等，同时岗位职责上进行分离，设置云平台相关运维岗位。

在云平台运维人员培养方面，主要采取以下措施：通过项目建设积累经验、从传统技术团队挑选一批、在实际运维管理培养一批人才等方式，逐步实现平滑过渡。

采取多种方式提高运维人员的技能水平，具体是以实操演练、原厂培训、外部认证等多种方式，加快行内技术人员的培养。自22年截止目前，共开展3次原厂培训和5次自主XC技术专题培训，有效提升我行人员对于XC技术的运维能力。同时结合ISO20000管理体系，逐步建立了云平台、网络安全、操作系统、数据库和中间件等8类XC产品的操作规范、安全基线、应急手册等运维标准，有效地指导运维人员的工作，提高运维效率和质量，构建了以行内人员的运维团队保障体系。

二、项目创新点与特色

（一）建立应用上云标准

制定我行在应用是否上云以及如何上云方面的技术标准，以规划全行业务系统上云建设和金融云体系建设，充分发挥云平台的价值和优势，实现云上业务系统的统一、科学、高效运营管理，推动业务创新发展。

（二）构建全新管理体系

提出并构建“分散运营，集中管理”体系，旨在让省市各支行运营更加灵活，发展更加多元化。同时减少不同分支行在管理人员上的重复投入，降低人力成本，更集中高效地解决问题，提高我行的业务运作效率。

（三）实现安全运维保障

建设我行在两朵云上针对省市支行的运维体系，确保我行云平台实现持续检测、持续安全的安全战略目标。建立良好的运维保障机制，通过对运维手册优化、监控告警、系统巡检、备份管理、容量管理及流程质量分析及优化多方面保证我行云平台能够更加安全、稳定的持续运行。

三、项目运营情况 

通过建设“多云运维体系”，项目试点的成功实施，取得了较好的应用效果。目前XC平台包括76 台服务器及网络设备、117套操作系统、26 套数据库、14 套中间件及云计算平台，投产了全渠道客服等8套应用。共完成125次扩容等、12次连续性演练及8次版本更新。2023年*****季度，共开展了3次原厂培训和5次自主XC技术专题培训，有效提升XC技术运维能力。

四、项目效能评估 

自 2020年12月启动以来，项目历经考察、规划、地市、行需求调研、试点项目开发和验证、投产、推广和培训等重要阶段，真正实现了“小投资、大效果”的建设目标。具体体现为： 

（一）业务上线交付效率快。以前地市法人行自建方式需要经过技术栈适配、压力测试、模拟上线、正式上线等环节，平均需要 6-7 个月，同时因地市法人行技术能力参差不齐，需要省行提供技术支持，无疑加大省行人员工作量，拉长业务适配上线周期。制定应用上线规范可让地市法人行对应用自我匹配，增加效率，减少工作量，大大节省了业务适配上线周期长所产生的成本。

（二）集中管理人员投入低。针对 76 个独立法人单位的现状，项目的实施解决了多法人体系下各自为政的建设混乱局面。建立统一的运管平台，由省行进行资源的统一管理，地市法人行只需使用资源，大大降低地市法人行运管人员投入。

（三）运维支持保障能力强。通过安全运维体系的建设，搭配相应设备，实现全省法人行互联网业务安全出口的加固，有效提升市县行现有互联网应用安全防护能力。综合降低地市重复性建设和运维相关成本50%，同时运维效率提升 75%。

五、项目小结 

项目建立“多云运维体系”规范，通过采用“分散运营，集中管理”的方法论，完善平台架构规范。多法人体系的”两朵云”平台运维保障，不仅解决了多法人行各自为政的资源管理难题，节约了基础建设投入成本，更好地保障了数据和业务的安全性，同时也将湖北省联社科技资源和系统运维面向各市州农商银行输出，打造了全省农商银行互联网产品运维中心、创新中心，更好地支持全省农商银行业务发展。