HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

一百多应用运维面临挑战,开源“走不通”|广州银行信用卡中心的自动化运维实践

  • 2023-05-24
    北京
  • 本文字数:4446 字

    阅读完需:约 15 分钟

一百多应用运维面临挑战,开源“走不通”|广州银行信用卡中心的自动化运维实践

采访嘉宾|陈晓岚,广州银行信用卡中心运维与信息安全技术负责人


在全国地方城商行中,广州银行是全国第二家成立信用卡中心的城商行。


因为信用卡业务的特殊性,往往会促使商业银行在信用卡方面的科技应用进度条要快于其它业务。比如,由于信用卡没有网点,这就使得它更早实现线上化运营;再比如,信用卡业务与个人征信、消费分期、移动金融等都有着强关联,加上在审批、风控、运营等方面的高要求,使得信用卡中心的数字化、自动化步伐也迈得更快。


广州银行自 2011 年开始发行信用卡;2016 年,专门成立了信用卡专营机构,即广州银行信用卡中心。而自广州银行信用卡中心成立以来,金融科技便在信用卡业务的各个环节扮演着关键角色。


举例来说,在信用卡风险管理场景,通过引入大数据和 AI 技术,广州银行建立了一套精细化的风控体系。在营销展业环节可以了解客户属性,进行风险前置;同时,在催收环节,也可以实现智能催收,基于标签提升催收效率,并持续优化催收策略


值得关注的是,作为零售业务,广州银行信用卡中心面对的是数量众多的零售客户。随着近年来信用卡业务的持续增长,以及产品类型的逐渐增加,要确保精细化且高效的管理和运营,对底层系统稳定性、灵活性、扩展性要求越来越高,传统 IT 系统运维的问题也逐步暴露出来。


在这样的背景下,广州银行信用卡中心在去年上线了自动化运维平台,进行 IT 运维升级。围绕这一平台构建的初衷、实践历程以及背后的思考逻辑,InfoQ 采访了该项目的产品规划和技术统筹实施负责人——广州银行信用卡中心运维与信息安全技术负责人陈晓岚。

涉及多个应用系统,发布效率和质量面临巨大挑战


虽然广州银行立足于广州,但是其业务范围辐射整个珠三角,除此之外,在南京也设有分行。这意味着,广州银行不仅要跟本地银行竞争,还要跟全国性的国有大行和股份制银行竞争。如何在这样的激烈竞争中赢得更多的市场份额,作为城商行必须找到具有特色和个性化的突破点。


据陈晓岚介绍,广州银行信用卡中心的业务主要面向 C 端客户,需要对客群进行更精细化的管理和运营


“一方面,既需要我们能够把更优质的客户筛选出来;另一方面,也要能够对个人在贷前、贷中、贷后全流程的风险进行管控,包括贷前的获客,贷中的客群分类、产品推荐、风险分级,以及贷后的回款追踪等等。在这个过程中,涉及一系列精细化的运营动作,这些动作需要对应的系统去做支撑。”


陈晓岚告诉 InfoQ 记者,过去,广州银行信用卡中心大大小小的应用系统较多,包括不同的类型,面向不同的业务模式服务。并且,消费类信用业务需要根据市场环境、监管要求频繁做调整。


在自动化运维平台上线之前,广州银行信用卡中心的大部分应用系统发布都靠人工部署,一旦涉及变更的系统数量比较多,其中的工作量和耗时可以想象,应用的整体发布效率面临巨大挑战。


另一个挑战来自于发布质量。周期性的任务执行,比如脚本和配置等等,如果不进行集中、系统化的统一纳管,可能造成系统对人的依赖性很高,如果出现人员交接,或者需要对突发问题进行排查,效率比较低,系统稳定性也可能会受到冲击。


此外,系统非常依赖运维管理的完善性——比如,发布版本包命名管理规范;以及发布过程需要有效的回溯、审计措施,需要及时对投产日上线发布成功与否进行有效的统计等等。这一系列的管理如果存在问题,将影响应用的发布质量。


“繁琐复杂的运维工作,将会使得人力无法释放,可能导致每一次投产,投入的运维时间成本和人力投入非常大。”陈晓岚强调,“这就是我们去建设自动化运维平台的一些导火索。换句话说,前台业务的变化对后台的要求越来越高,我们必须不断适应业务场景的需求,持续提升开发运维效率。”

尝试基于开源做自动化发布编排,不断尝试调整适应


系统的稳定性、灵活性、扩展性以及响应速度是保障业务高可用性的重要前提。陈晓岚说,这些要素就是广州银行在做技术选型的过程中非常看重的部分。


也正因为如此,广州银行信用卡中心区别于传统的商业银行信息系统建设思路——强调开发和管理流程建设,而弱化运维工作的优先级。“我们认为,即便是后端运维,一旦出错,对生产环境的维护效率也会带来巨大影响。所以,我们一直把前端开发和后端的运维、流程管理视为一个密不可分的整体,在每个环节都会持续去做迭代优化,而不是更侧重哪一部分。”陈晓岚表示。


事实上,早在此次自动化运维平台上线之前,广州银行信用卡中心就在自动化运维方面做了大量探索和研究工作。时间最早可以追溯到 2018 年,陈晓岚及其运维团队就参考了当时互联网公司自动化发布的模式,基于开源技术去做自动化的发布编排。


陈晓岚向 InfoQ 介绍,最开始团队之所以选择使用开源工具,主要原因来自几个层面:第一,开源的方式可以快速部署和落地,帮助前端业务更快去做模式的探索和实验;第二,开源技术比较灵活,不涉及太多的选型,有一定的试错空间,如果部署后发现不可行,就能立即更换,不会浪费太多资源;第三,希望基于开源,对内部的技术人员有一些能力方面的提升。


然而,银行和互联网公司的业务特点毕竟有着明显差别,开源模式需要结合实际情况不断调整适应。比如,互联网公司大部分应用都部署在公有云上,在基础平台层面基本不需要做管理,因此不存在管理方面的挑战;再比如,互联网公司对安全性的要求没有银行那么高,物理环境也相对简单。


而银行的物理环境、技术栈远远要比它们复杂得多,通过开源自研的自动化发布生产线上线之后,能够对接的系统有限,根本无法做到平台化,并且随着系统越来越多,问题就越来越明显


“所以,我们引进外部自动化运维平台,把所有的应用系统发布全部放到平台上统一进行管理,就是希望应用发布同时兼顾稳定和效率,实现标准流程化、应用发布自动化的目标。同时,也希望能够基于这些商业化平台的案例实践探索,更好地解决我们面临的一系列问题。”陈晓岚指出。

从事前、事中到事后落实技术管控和流程管理,确保系统稳定性


那么,广州银行信用卡中心是如何结合自身情况对自动化运维平台的技术路线和产品进行选型的?陈晓岚表示,当时团队主要围绕以下四个方面做了着重考量


第一,由于场景很复杂,所以这个平台必须在比较多的企业场景有过实践和验证;


第二,它必须能够满足多种技术栈的发布需求,包括蓝绿发布、灰度发布和滚动发布等等;


第三,这个平台需要具备一定的操作便利度,比如能够通过低代码支持快速实现编排,当有系统新增的时候,也能快速进行操作;


第四,这个平台本身的源代码能够一定程度上做开放,因为其业务调整比较频繁,这样的话便与做一些二次开发。


从这几个角度出发,最终广州银行信用卡中心通过打造应用发布自动化能力建设,启用应用发布中心(如下图)。



在陈晓岚看来,自动化运维项目的上线和实施,非常核心的一个点在于,不能为了自动化而做自动化,而是企业在其中确实有比较大的痛点。


如前面介绍,结合系统多而且复杂的现状,避免因手工操作影响效率的情况。为了简化多技术栈的问题,同时分担运维人员的工作压力,引入自动化运维平台。“因此,我们的规划其实也是围绕这些点展开的。先明确目标,然后分步骤落实。在这个过程中除了技术之外,还会涉及一些配套的管理模式的优化,需要从管理效率上做到整体提升。”


值得注意的是,广州银行信用卡中心建设的是一个“平台”而非“工具”,这个平台目前主要包括了配置中心、应用发布、作业平台、标准运维等主要的部分。“现在,我们所有的开发运维工作基本上都是以它为基础去实现的,包括生产的发布、生产维护、版本发布,以及版本回退等等,基本上相当于一个底座的角色,基于整体的底座,后续还会有一系列的功能拓展。”陈晓岚表示。


既然是“底座”,系统运行的稳定性必是首要前提。对此,广州银行信用卡中心的核心思路是技术管控和流程管理并重,根据时间条线,把技术管控和流程管理分为事前、事中、事后三个关键步骤,并且层层落实:


首先,事前要重预防,这跟基础架构的整体设计、系统研发的高质量保障等等有很大的关系。拿基础架构来说,如果最开始没做好,后面肯定就会有很多修修补补的动作,需要人的介入,从而引发后续一系列的连锁反应。陈晓岚表示,如果这个环节能够做好,基本上就解决了 70%的稳定性问题;


其次,事中要重监控,持续关注隐患发生的可能性,并在发生之后快速进行处理和修复,这个环节对稳定性的影响占 20%。通过自动化运维平台,能在这个过程中快速实现重启和切换,减少人工操作,让业务稳定性更高;


最后,事后要重闭环,也就是说在问题发生之后,要跟踪复盘,形成闭环机制,找出根本原因是什么。

管理和技术的“坑”都踩过,平台已成为业务创新的扎实“后盾”


回顾整个项目的实施落地历程,陈晓岚坦言,自己和团队也踩过不少坑,其中的难点主要来自两个方面:


一方面与管理相关,因为项目涉及的团队和人员角色比较多,需要多方协同,期间涉及很多沟通协调问题;另一方面与技术相关,此前的系统应用发布顺序不一样,并且很多都归属不同的安全区域,要把它们统一放到平台上,会涉及很多技术方面的调试和任务拆解。


陈晓岚强调,“当然,其中技术其实是相对可控的,比较好解决。但‘人’的问题是比较棘手的。针对这个问题,管理层面的规范非常重要,需要通过固定的流程,用比较长的时间慢慢改变人的习惯。 我们自己也在这一方面花费了比较多的时间,包括做一些技术上的适应,以及管理上协调。”


举例来说,针对人的问题,广州银行信用卡中心在内部成立了一个大项目组,把关联的核心人员都拉进来,主要涉及软件工程管理及业务务团队中的关键角色


通过这种方式,职责更加明确,团队之间可以更好地进行横向和向上的沟通。“其实很多时候大家并不是不想配合你做事,而是在很多事情不明确的状况下,他很难理解具体的目的和意图,导致项目推进困难。而有了项目组,就可以拉齐大家的意识,分工更加明确,项目推进起来就会顺畅很多。”


如今基于自动化运维平台,广州银行信用卡中心完成了多套业务系统的应用发布,支撑近百次发布任务,几百+应用节点,接入主机数几百+,大幅提升了生产上线交付效率,实现有质量的应用敏捷交付。


陈晓岚认为,最直接的两点改变,一是应用整体发布流程更规范,二是发布和运维效率提升比较明显。比如,可以实现一键重启自动化安装、自动化回退等等,并且在处理故障的过程中,速度也更快。以前端移动展业系统为例,此前整个流程全部走完,一次大概需要一个小时,现在通过自动化运维平台,5 分钟左右就能搞定。


反馈到业务层面,如此高效的应用发布意义重大。“首先,快速的应用交付,可以帮助业务快速迭代、优化,包括在这个过程中,如果稳定性可以保障,那么也能给业务人员更多的信心,更大胆、更高频地去做创新;其次,当系统出现异常,我们可以快速通过一键回退解决,这中间可以减少很多故障时间,减少对业务的次生伤害。”陈晓岚说。


换言之,如今广州银行信用卡中心的自动化运维平台,已然成为其前端业务快速试错和创新的扎实“后盾”,是其数字化转型过程中不可或缺的一块基石。


参考链接:

https://mp.weixin.qq.com/s/FG57squ5JKw1591vCB9k0A

https://www.fddnet.cn/2021/jiaodian_0616/784.html

2023-05-24 09:387874

评论 2 条评论

发布
用户头像
文中提到内部引入开源软件构建系统,遇到了对接其他系统的问题。如果有一个可以承上启下的网关,充当上下的翻译官,是否可以实现系统间更好的对接,就像是系统的数据翻译官。
2023-06-06 10:18 · 山东
回复
这个思路很好。有个网关作为过渡跟衔接确实这是解决多系统间技术栈不同的好方法,但是这个也会对我们技术投入提出新的要求,就是需要新增这样一个网关的开发,而这个网关的开发还只是作为专有场景的使用。不像商业化产品一样可以快速复制和应用,相对来说投入的成本和资源就会更多一些。
2023-06-07 09:57 · 广东
回复
没有更多了
发现更多内容

第一周学习总结

Thrine

UML用例图组件图部署图

熊威

架构作业-UML图

铁血杰克

作业一:食堂就餐卡系统设计

而立斋

食堂就餐卡 最用心

2020年6月10日 异常、断言和日志

瑞克与莫迪

作业二:根据当周学习情况,完成一篇学习总结

晨光

Week1命题作业

星河寒水

部署图 时序图 组件图 用例图

食堂就餐卡系统设计

慢慢来的比较快

week1学习总结

慢慢来的比较快

架构师和软件架构的理解

周冬辉

学习总结--Week1

吴炳华

极客大学架构师训练营

第一周学习总结

Young

【架构思维-学习总结】week01

chun1123

学习 架构 思维方式

孤狼王兴 | 互联网大佬往事

刘燕

AI 企业管理 美团

架构师成长心得

熊威

GitHub 热榜:轻量级无 Agent 的自动化运维平台!

JackTian

GitHub 开源 spug 运维自动化 监控管理平台

架构师如何做架构-开篇

铁血杰克

食堂就餐卡系统设计

Young

架构师训练营 第一周 学习总结

RZC

【架构思维学习】week01

chun1123

软件架构 UML

人工智能之机械基

码农神说

人工智能 程序员 加班

【架构师训练营】1 - 食堂就餐卡系统设计

悬浮

架构 UML 部署图

食堂就餐卡系统设计

Thrine

架构师训练营 第一周 命题作业

RZC

食堂就餐卡系统设计

Linkin

食堂就餐卡系统设计(第一周作业)

Geek_237932

架构师 week 1 作业一

iLeGeND

Week 01 学习总结:UML图

鱼_XueTr

第一章作业

李白

作业一:食堂就餐卡系统设计

晨光

第一章作业-学习总结

李白

一百多应用运维面临挑战,开源“走不通”|广州银行信用卡中心的自动化运维实践_研发效能_高玉娴_InfoQ精选文章