中小银行数字化转型过程中，集中架构环境下运维+架构人员如何转变

字数 4601阅读 10201评论 2赞 4

目前本人就职在一家中小银行，负责整体运维工作，因为银行规模属于中小银行，则在运维业务系统的同时也要负责系统相关的规划工作，如何保证当前系统的正常运行，如何保证对后续建设业务系统的有力支撑，是我需要面临的工作。

我行作为中小银行，其架构采用的是较为标准的集中式架构，即行业普遍采用的以商业闭环软件为主的稳定架构IOE架构，在上线初期，这种稳定的架构模式帮助我们平稳渡过上线初期的业务适应期，避免业务频繁变更与系统故障产生冲突。

但伴随着互联网金融的强烈冲击，行内开始着眼于“传统金融”与“互联网金融”双核心的战略发展，开始着手数字化互联网金融建设，以至于当前传统的集中架构的问题逐步显现出来，当前架构无法适应业务多样化需求，无法做到敏捷开发，快速迭代，无法高效调配硬件资源，无法适应业务高发期与低谷期的快速转换，数据中心的科技人员疲于奔命，焦头烂额。

如何有力支撑行内的战略规划，跟上业务发展脚步，建设与业务发展相匹配的科技架构，这是我们需要深入研究的，而且作为中小银行，面临着科技投入的限制，如何利用有限的资源打造出优秀、合理的科技架构更加让人头疼。

面对如此问题，作为中小银行的科技人员如何应对？目前本人也没有探索出一条好的出路，仅仅将自身的体悟略述一二，以起抛砖引玉之效，望诸君共勉。

作为银行业的科技人，个人认为以下的5点需要做到，这样会避免走很多的弯路，工作起来更加高效：

# 一、 了道、合道：

所谓了道既是了解行内的战略发展规划，一般银行都会制定一定年限的战略发展规划，这些战略发展规划都是行内根据自身的经营状况，结合国家、地方、相关监管结构等发布的相关政策制定而成，指导行内未来一段时间内的发展策略，经营方针，对于科技来说，则是行内想要发展什么对应业务，科技要提供什么样的科技系统给与支撑，了解了这些，对我们的架构设计、架构改造、技术发展路线将有极大助益；

所谓合道则是将我们的架构设计、架构改造、技术发展路线与行内战略发展规划相结合，否则你设计的架构、走的技术路线不符合行内业务发展需求，必定被驳回，行内也不会对你的设计及技术投入给与大力支持，毕竟没有哪个企业肯只投入不求产出，此合道也对应“业务引领科技发展，科技助力业务增长”。

# 二、 敬道、参道：

所谓敬道既是敬重领导，多向领导汇报，多听取领导意见，这正承接了道，因为领导所处的位置，必定拥有更加多的资源，能够更加深刻的理解行内的战略发展规划，纵使其不能透彻行内的战略发展规划，当你多向领导汇报之后，多与其交流后也会使其对行内的战略发展规划加深了解，而且结合其手中更多的资源，了解到的更多的信息，给你反馈后也会帮助你加深对行内战略发展规划的认知，而且你尊敬领导意见的同时，其会投桃报李，给与你更多的帮助；

所谓参道则是仔细参悟领导意见，多将领导给与的信息与你对行内发展规划的认知相印证，去芜存菁，加深你对行内战略发展规划的理解，不要做出偏离行内发展规划的错误设计，避免辛苦设计出来的东西不被赏识，无法落地实施；同时参道也是对行内发展规划的仔细体悟，务求事半功倍，莫要事倍功半。

# 三、 借道、悟道：

所谓借道，在银行业中，个人认为是借助乙方的力量，一般情况下，每个银行都会有很多合作比较好的乙方公司，而且乙方公司乐于与银行进行交流、合作，每个银行的科技人员数量有限，其掌握的技术涵盖面也有一定限制，精力也有所掣肘，但是技术发展速度是空前快速的，技术面宽广无边，银行科技人员不可能总做到技术领先，事实上我们在一定程度上还处于落后阶段，毕竟银行求稳，那么新技术的使用也不会是第一个吃螃蟹的，在这种情况下就要多借助乙方的能力，大多数乙方公司不仅仅为银行业服务，也为其他很多企业服务，大部分新技术都会在某些行业有落地的实施经验，这个时候我们银行业多与乙方公司进行交流沟通，让他们为我们引进新的技术理念，新的架构设计思想，必定会为我们自身设计符合行内业务发展要求的架构提供宝贵经验和数据佐证；

借外道，悟己道，借助乙方力量可以给我们自己的设计思想提供极大助益的同时也要进行辨别，毕竟不是每个乙方的技术思想都是我们需要的，那么就要通过体悟自身需求，对邀请交流的乙方进行甄选，挑选合适的乙方产品进行一定程度的交流、了解，对于符合行内发展规划，并且对自身设计思想有极大助益的更是要深入交流。

# 四、 融道、助道：

所谓融道即将自身融入团队当中，加强团队协作能力，加强团队内部沟通，互相印证，互相帮助，“没有一个人是一座孤岛”；

即融道，则得众道之助，“思想碰撞会擦出耀眼的智慧火花”，“众人拾柴火焰高”次之谓也，一方面通过与他人的技术讨论可以完善自身技术思想的欠缺，也可以迸发出新的思想，解决困扰己身的技术难题；一方面好的技术思路需要团队的配合进行实践与检验；

关于融道、助道不仅仅适用于银行的科技人员，也推之泽广，不详述之。

# 五、 修道、精道：

所谓修道谓修己道，作为一名科技人员，必须对自身能力有所要求，常怀向学之心，IT技术发展日新月异，对比农业、工业等有“半年半个世纪”的说法，如果以倦怠之心事IT之业，则如逆水放舟，行之远以，设计出来的东西，采用的技术方法不符合时代的潮流，不符合行内的发展规划，被弃之如敝履，也会被踢出科技队伍或放之角落任其堕落；

精道之言筑于修道之上，有向学之心固然重要，但人的精力毕竟有限，学习也要量力而行，不必贪心不足，出来新技术就去学习，会贪多嚼不烂，个人认为应该是先视之面，再深入一点，即先大概了解行业的技术多样化，再结合自身状况、行业特性抓住一点深入学习，然后再横向拓展，补齐大面，这样在架构设计时才能有所建树，否则设计出来的内容多有浮皮潦草之处，难以落地。

以上仅是较为共性的说辞，略述如何更好开展工作，至于转型期我所面临的问题以及如何解决此种种问题，将在下面进行介绍。

我行坚持服务“三农”、服务中小、服务社区的市场定位，坚定走差异化、特色化经营之路，结合自身情况，制定了以“E码付”、“税鑫贷”、“房E贷”等线上服务类业务为重点的特色发展道路，针对这类拳头业务，信息科技部也坚定了信息科技的数字化转型之路，数字洞察驱动帮助业务进行客户定位，模型自动化决策帮助业务进行精准营销、客户管理及产品创新，鉴于此，大数据平台建设成为我行当前科技发展的首要工作。

**那么在行内数字化转型的道路上，作为架构设计者又需要做出如何的转变，如何的丰富自身，以提交满足业务需求的架构？**

# 一、 深入理解业务

当我作为一个科技人员，只负责实施、维护时我在意的仅仅是如何将系统部署准确，能够对外提供服务，并且尽量避免业务系统出现故障，并保障其性能，避免出现业务并发量过大，导致的系统夯死状况发生，但是作为一个平台架构的设计者就不单单要考虑业务系统的可用性，而且要保证客户满意度，也要从业务的角度考虑架构的适用性，不是为了实践技术而设计架构，是为了业务发展而设计架构。

因为本人是做的硬件架构设计，所以对于深入理解业务需要从两个方面入手，一是理解业务特点，二是理解业务系统架构；

基于业务特点，行内开展线上特色业务都有固定的目标化人群，针对此类人群做精细化营销，而此处正可用到数据洞察驱动，做好客户定位，也可用到模型自动决策来组织精准营销并做好客户管理，而这些都是可以通过大数据平台的建设，并完成数据治理后来实现的，因此我们需要大数据平台，并且平台需要海量数据作为支撑；

基于业务系统架构，既然确定大数据平台可以解决业务需求问题，那么大数据平台的需求又是什么，什么样的硬件平台更加适合大数据平台的建设？通过技术可用性的考量、成本投入的考量、平台稳定性的考量等等，确定以X86为基础的分布式架构作为大数据的支撑平台。

# 二、 思想观念转型

个人作为传统架构运维出身，在职业生涯中建立了一个一切追求稳定的固有思想，进入银行业后，每天领导耳提面命的仍然是稳定、安全，全年实现0故障、0风险是我们追求的极致，银行系统一宕机会造成社会恐慌，造成公众混乱，这从某种角度上来说是正确的，国家也明文规定银行不允许破产，但是在运维过程中会发现银行的系统是分层次、分级的，只要关键系统，比如核心、柜面这样的不中断，那么是不会造成太大的社会影响，银行在当前的社会形势下要发展就不能过于固步自封，业务上要有新的收入增长点，科技部门要能够采用新技术跟上业务的增长，科技人员要敢于使用一定的新技术，否则银行的利润会越来越少，最后就是被接管或者收购。

对于我而言，就是需要将稳的思想稍稍转变，比如计算资源并非必须追求小型机，是否可以使用多台X86代替，只要冗余性、高可用性做的足够，未必不能替代小型机；存储并非追求EMC、IBM，对于非关键性业务是否可以使用其他国产存储，或者采用分布式存储技术，X86代替以往国外集中存储。

那么基于X86的分布式架构的实现则成为一项较为令人满意的选择，而且建筑其上的大数据平台又并非帐务交易系统对于稳定性的追求也没有核心帐务系统那么苛刻。

# 三、 分布式必要性

当前社会形势下，国家经济从粗放式发展转型到精细化发展已经多年，只要肯投入就会有产出的经营模式已经脆弱不堪，企业的经济投入都是建立在量化考核回报的基础上实施的，那么多元化的信息收集就变的更加重要，而大数据平台正是基于这种社会现象而产生的概念。因为当前数据存在形式较为多样化，那么传统的关系型数据库无法解决这样大量、分散、多种存在形式的数据存储及分析，那么基于此的分布式计算、分布式存储、分布式数据库等技术就应运而生。

我们研究分布式，研究这种技术的使用能为业务带来怎样的好处，则非常必要。

# 四、 借鉴乙方落地经验并反复印证行内自身发展需求

确定了以大数据平台建设来支撑行内业务发展的目标后，我们设计的架构是否符合行内行内业务发展需求，是否能够最大限度的降低成本，是否能够保证架构的稳定性、高可用性，这些都需要在架构落地实施前有所评估，如何评估那？个人认为非常有表要借鉴乙方的落地经验对自身设计进行反复验证，乙方为多数公司服务，每个公司在架构设计或者实施的过程中总会遇到各种各样的问题，乙方在为多个公司的服务过程中会积累大量的设计或实施经验，我们通过与方法公司的密切交流合作，获取更多的设计思路和实施经验，这样再印证我们自己的设计思路，再结合行内业务情况就会将我们的设计更趋完美，落地实施时也会减少阻碍，这样项目整体的实施时间会大大减少，成本得到降低。

# 五、 了解行内经营状况并对架构实现成本有所评估

架构设计的再合理，再贴合业务，没有领导的批示，没有公司的投入也是无用，我们的架构设计实施要充分考虑到成本投入，这和行内的经营状况息息相关，比如行内每年净利润仅仅2亿，我们要用1亿去进行科技项目的实施，那明显不现实，所以架构设计人员的成果物是需要与行内经营状况相匹配的，我们也要了解行内的经营状况，避免辛苦努力一场空。

# 结语

在银行体系变革风暴的影响下，作为其科技工作者需要将自身价值追求与企业价值追求相融合，要适应经济形势的变化，更需要对自身能力精益求精，同时要总结自我工作方法，形成自我工作体系，对于工作要有的放矢，切记缘木求鱼。

数字化转型集成架构互联网金融分布式架构

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！