本文来自微信公众号“twt企业IT社区”。
国家信创战略在金融行业推进历程已有三年，很多金融企业已经开始或者完成了信创项目的落地，但是在落地的过程当中会存在同样的困惑。从哪里开始着手最合适，这可能是很多准备开始信创战略的金融企业面临的首要问题，着眼点选择得当就会使得信创项目能够安全稳定落地，着眼点选择不得当，很有可能给企业的业务带来风险，同时给现有稳定环境带来问题。所以有必要集各家之精华供同行思路参考。
【栏目主编】赵海某金融系统高级主管：本议题由某省农信资深技术经理雷智、北部湾银行技术经理哲哲蛙、技术专家洪烨发表针对议题下关键点的主张，几位专家的主张在某金融科技公司高级技术主管张鹏、利安人寿资深工程师陈萍春及我本人等多位专家的复议后，形成了一定的共识，希望可以对同行有一定的参考。
雷智 某省农信资深技术经理：
信创架构与业务场景的融合设计应当“高处着眼，低处着手”，脱离业务场景的架构设计如同缘木求鱼。
一、引言
金融行业作为国家信创战略全面推广试点的唯二行业，通过近3年的试点，取得了瞩目的成绩。在金融行业信创试点中，各试点机构始终面临着信创基础架构与业务场景如何科学合理的融合设计问题。本文从信创试点实践出发，介绍信创架构设计所面临的难点、设计原则、选型策略等重点内容，以供同业参考。
二、信创架构设计所面临的难点
1.产品功能仍需不断完善
信创产品在过往的发展中不断优化完善产品功能，特别是近几年的信创大趋势下，加快了产品的更迭完善速度。但相较传统成熟企业级IT产品，仍在产品功能、性能、兼容性、稳定性等方面存在一定差距，还需在各行业应用中不断完善。
2.产品生态尚在逐步培育
IT产品始终处于动态发展之中。健全的研发、销售、售后的产品生态，原厂及第三方的售后技术生态，是信创产品走得稳、走得远的关键因素。虽然近年来，各主流信创产品厂商均在“大干快上”地建立产品生态，取得了一定成效，但与传统IT产品生态仍有一定差距。
3.可供参考借鉴经验较少
降低投资和运营风险是大多数企业客户在选择IT产品时的重要考虑因素。近年来，主流信创产品在党政军、运营商和金融等行业进行了大量试点开拓，但由于行业、场景、组织和能力等方面差异，信创产品实际落地的可借鉴参考经验较少。
4.监管及运营双重压力
信创产品的成功，不仅在于建成，更在于用好。以银行业为例，IT建设和运营始终面临着监管及运营的双重压力。一是监管指标是底线。信息系统运营风险作为操作风险的重要组成部分，一直是银行监管部门的重要考核指标；二是自主运营的要求。在监管要求和自身发展的要求之中，银行业必须坚持“只能外包工作，不能外包责任”的监管要求，同时兼顾商务合规、技术自主、生态可控等原则，保障信创产品的高效、稳定运营。
三、信创架构设计原则
“应用尽用”，“用信创是常态、不用是非常态”的大趋势之下，如何设计信创架构，并与业务场景相融合是当前架构设计所必须解决的问题。
1.基本满足业务需求
信创作为当前大趋势，也是试点机构的所必须完成的监管任务。在当前IT投资有限的情况之下，在信创架构设计中，一定要基于业务场景，选择满足业务需求的相对成熟和主流的信创产品，躬身入局。
2.相对主流成熟技术
信创产品在近几年的大发展中，虽然市场格局尚未明朗，但已逐步呈现相对稳定的头部梯队。相对主流成熟的技术产品，经过市场的洗礼，案例较多、产品相对更为稳定、高效，生态也更为成熟，降低信创产品架构设计和后期运营中的风险。
3.适当采取多技术栈
技术及产品的市场需求差异大、更迭速度快、成型周期长。特别是当前信创产品种类繁多，鱼龙混杂，多技术栈均在赛马期，未来发展趋势尚不明朗。因此在信创架构设计中，尽量在每个产品维度选择当前2-3种主流技术栈的主流产品，降低产品选型的机会成本。
4.兼容性广生态健全
当前信创产品的局限之一就是兼容性不足，主要存在于对传统主流西方主导的IT技术栈和信创产品之间的两种兼容性。兼容性的不足也限制了信创产品使用场景广度和深度，而信创产品的兼容性高低与其厂商的生态成熟度成正比。因此在信创架构设计中需考虑产品的兼容性及生态健全程度。
四、信创架构选型策略
1.优先借鉴同业案例
“他山之石可以攻玉”。经过同业适配、验证并投产使用的信创架构是我们信创架构选型的重要参考。虽然行业、场景等存在一定差异，但有同业案例的珠玉在前，我们不仅可以少走弯路，也可在后期运营中相互学习交流。
2.符合技术发展趋势
发展信创的首要目的是冲破“卡脖子”的枷锁，实现自主可控。我们不仅需要考虑“产品平滑替代”，也要考虑“产品升级替换”，在解决当前“可用”后，向“好用”发展。因此，我们在信创架构选型时，也要选用符合技术发展趋势的信创技术产品，如云计算、分布式架构等，为企业技术发展提前做好技术储备。
3.匹配内部科技规划
当前信创虽是任务，但已然成为趋势。若为任务而信创，脱离企业科技规划，如同本末倒置。我们应该依托企业科技规划，加入信创因素，寻找更为适合的切入点，将两者有机结合才能事半功倍为业务发展赋能。
4.选取共性搭建底座
在信创架构选型中有芯片服务器、操作系统、数据库、中间件等众多产品可供选择，但如云平台、超融合、虚拟化等可复用、有共性的底座型技术决定了企业未来信创技术线路的选择，不仅需要优先考虑，更应结合企业科技规划科学统筹考虑。
5.支持全栈留有余地
信创的内涵十分丰富，道路千万条，安全第一条。对于企业来说，信创架构设计的安全，其关键点在于架构的兼容性、可靠性及可持续性。优先支持横向和纵向全栈信创：横向同一品类，支持主流多品牌信创厂家产品；纵向自下往上，支持主流多品类多品牌信创厂家产品。一是信创改造方案更为灵活。二是信创架构更为开放。三是信创生态更为可控。
五、结语
信创架构与业务场景的融合设计应当“高处着眼，低处着手”，脱离业务场景的架构设计如同缘木求鱼。在信创架构设计中需要坚守基本满足业务需求、相对主流成熟技术、适当采取多技术栈和兼容性广生态健全的设计原则，采取优先借鉴同业案例、符合技术发展趋势、匹配内部科技规划、选取共性搭建底座和支持全栈留有余地的选型策略，以此长远规划、先行先试、步步为营、边走边调的策略，在金融科技赋能业务高速发展的康庄大道上奋进。
哲哲蛙 北部湾银行技术经理：
为了提高金融行业自主可控能力，提高企业安全性，金融企业应当加快信创改造的步伐，但信创的基础架构和业务场景融合并不能一蹴而就，金融行业需要全面了解自身所处的阶段，对自己企业的场景进行分类分析，加强企业间沟通合作，经验分享，全行业通力合作进行信创攻关，提高行业整体信创改造效率。
一、引言
金融行业自2020年信创元年启动信创计划以来，历经3个年头，截至2022年已有超过千家金融单位加入信创改造浪潮，2022年银行业信创试点机构已扩容至400余家，目前银行业的信创化改造已经进入信创改造深水区，国有大行和全国性股份制银行的信创建设开展较早，目前已经有部分机构例如邮储银行已完成了核心系统信创改造，而其他股份制银行、城商行等改造进度目前因存在启动时间和行内信息化建设现状存在差异，目前改造程度参差不齐。不同特点的业务系统对于信创改造的要求和改造思路通常也会存在差异，管理类、业务类系统因对银行机构正常工作和业务开展的影响程度不同，不能一概而论采用同样的规则去进行一刀切，不同的业务场景是需要不同的基础架构进行支撑，因此金融行业信创基础架构与业务场景的结合设计不能一蹴而就。
与信创相关的基础架构包括IT基础硬件设施如CPU芯片、服务器、存储、交换机、路由器、各种云和相关服务内容，信息安全类基础架构包含边界安全产品、终端安全产品等，此外信创的基础架构中软件包含数据库、操作系统、中间件。应用软件：OA、ERP、办公软件、流版签软件以及各类金融应用系统。银行行业内，也在逐步组织进行业务场景的细分，并鼓励不同金融单位在不同业务场景上进行尝试，通过不同的路线或基础架构提供改造支撑，通过对各家银行信创典型案例的整理，并形成示范效应。
二、信创目前国内金融改造格局
国内的信创自2014年起步于“安可”，先从政府信息工程试点，后续逐步向金融等其他行业推广，从全局观察信创趋势，国家公布的《“十四五”国家信息化规划》和多个文件显示，信创产业作为国家战略，意志坚定，毫不动摇。
金融行业信创在2020年开始，被称为“金融信创元年”，2020年8月，金融行业信创一期试点启动，试点机构47家，主要包含银行、保险、券商，银行业也从国家政策性银行、国有四大行、地方性城商行、合资银行找了具有代表性的机构进行试点，改造范围主要集中在银行的内管等不影响银行主要业务的场景；2021年金融行业二期信创则将机构扩容至198家，试点业务场景除了内管场景外还加入了银行对客业务类场景，一方面要求银行机构在OA&邮件系统替换成全栈信创产品；另一方面，一般业务类场景的系统开始全面推动信创应用，其中比较有代表性的银河麒麟正式上线建行信用卡业务，工行完成借记卡核心账户系统的国产化尝试，部分城商行甚至年内弯道超车，借助信创改造的机会直接完成了核心系统的上线改造，总体来看国内试点单位的信创投入比例随着时间往后的推移均在持续增加。
金融信创按照“先试点、后全面”的技术推广路线，在2022年扩容至全行业5000余家，银行业信创试点机构扩容至400余家，改造的业务场景全面开花，鼓励试点银行先行先试，全面覆盖银行业所有的业务场景。2022年部分机构例如邮储银行已完成了核心系统信创改造，进入全面推广阶段。
三、金融行业信创基础架构与业务场景的结合的问题以及思路
目前金融行业信息系统主要由应用系统、基础软件和基础硬件等三层构成，其中基础软硬件在前文中已有提及，而金融行业应用系统根据不同维度，基本可以按照渠道和场景、业务和服务、技术支撑三类进行区分。例如技术支撑类主要是包含技术平台、研发平台、运维管理平台等；根据渠道场景可分为渠道服务和场景服务等子类；而按照业务服务和服务维度区分，则可分为产品服务、管理支持服务、基础服务等子类。
信创目前在三个维度结合度中，与技术支撑类的结合紧密度最深，已经能较好实现例如云平台、大数据平台、研发平台、运维管理平台的深度结合，国内一些例如阿里云、腾讯云、华为云等云平台产品，早在2020年开始已经相继推出国产信创化适应产品版本。此外，国内目前主流的主要基于Hadoop生态或者国产MPP数据库类似金山、DWS等大数据平台，或者统一运维门户管理平台等应用，在大小银行落地案例已经很多。而在开发运维平台层面，金融行业较为注重自主开发能力，特别是四大行以及国有股份制银行，自主开发能力非常强，可使用的支持信创开发平台也较多，例如云厂商配套的开发框架腾讯TSM开发平台、阿里EMAS移动开发平台，或者应用集成商例如神码、宇信等基于Galax和Spring的开发平台、微服务管理平台。应用厂商的开发平台通常能国产信创支持，且公司基于信创开发平台开发了信创版本的应用软件适应技术潮流。但是可能因为在生态和应用集成厂商之间商业合作紧密度上不同，存在支持的框架开放性不足的问题，不一定能实现一个平台兼容所有市面上主流应用开发商开发框架需求。此类问题的解决，不能单单依靠某一个应用厂商，还需要国产厂商之间进行开放性沟通，构建良好的生态链的协调。
如果按照渠道场景进行分类，金融业的线上渠道和线下渠道的信创应用均已具备落地基础，但是在进行信创改造时也需要综合考虑其业务重要性以及改造时间表的安排。线上渠道较为重要的例如手机银行、网银、微信银行等，不同渠道业务量和金额大小不同，例如手机银行，更多的承载个人用户的相对小额资金交易业务，网银更多是承载企业资金交易大额业务。此类系统进行信创改造，通过JAVA进行开发的应用难度不大，但进行数据库选型时则需要结合业务特性选定能支持相应并发能力的数据库产品。目前国产集中式数据库，在高并发场景下对硬件服务器资源开销较大，单台信创服务器的计算能力可能成为其并发承载能力的瓶颈，网银等并发业务量相对小的数据库可以考虑进行替换，而对于手机银行等并发较大的渠道，则往往需要选择并发承载能力更高的分布式数据库，在产品选型中，需慎重考虑进行充分的性能和语法兼容性的评估，以及充分测试后再进行改造。线下渠道的信创化改造，主要面临两方面的适配：其一是线下机具的国产化替换，其二是相应系统服务端的适配改造。目前从技术层面已经较为成熟，只是在进行替换实施路径中，可以结合信创改造要求和网点改造升级、网点覆盖要求等方面进行统筹考虑。
金融行业核心业务场景离不开存、贷、汇，在前两批试点已经积累大量信创落地案例，例如贷款中的风控、信用卡、现金结算、个人贷款等业务场景，但仍有许多业务场景目前案例较少或者空白，究其原因在于不同的业务场景在进行信创化实施时可能会遇到不同障碍，例如票据、黄金等业务，需要在金融行业内协调银行、票据、黄金等进行同步改造，例如代收付业务，属于金融与其他行业联动的场景，往往需要业务关连端进行同步适配，才能完成信创改造工作。
四、未来信创基础架构与业务场景的结合的解决思路
金融业进行信创改造时，仍需按照合理规划、审慎递进的原则进行逐步推广，通过建设信创技术支撑底座、改造部分行内管理系统积累经验，按先管理再业务、从外围到核心进行逐层深化。
对于开展信创工作时间不长的金融单位，在进行一期系统的探索改造中，需提高认识，积极积累更多经验，例如数据库技术领域，需要同步积累国产集中式、分布式数据库技术知识和经验，积累具备高并发、高安全性等特性的一些系统改造经验，应用层面，需要结合自己单位对未来应用架构的设计规划，针对虚拟化改造方案、容器和微服务化改造方案并行探索，建设基础云平台，选定相应的云服务逐渐推进。在对业务类系统进行改造前，宜先对自身业务场景进行归类分析，先选择相对较为独立的、可以自主实现改造的非关联系统进行改造，避免需要同时协调多个关联行业才能改造的情况。在对单个系统的改造方案制定过程中，多了解同行的改造实施情况，在同业有参考案例的情况下，结合自身技术路线选型，尽量减少不必要的适配开销。在前期的试水改造中，培养和吸收相关专业技术人才，做好人才和知识储备，为后续的业务系统信创结合打下基础。
金融企业间可以多组织同业沟通交流，不同规模，不同性质的金融单位可能有着不同的业务特点，金融单位在放眼全行业的同时，可加强与本身管理、技术路线相似度较高的单位深化沟通，分享场景的改造案例，在行业内统筹改造，在无参考案例的场景领域，形成局部或者行业内的信创改造联盟，每个成员选择一到两个无案例场景，集中精力进行场景信创突破，完成实施后进行经验共享，以实现整个行业分工协作。
五、结语
为了提高金融行业自主可控能力，提高企业安全性，金融企业应当加快信创改造的步伐，但信创的基础架构和业务场景融合并不能一蹴而就，金融行业需要全面了解自身所处的阶段，对自己企业的场景进行分类分析，加强企业间沟通合作，经验分享，全行业通力合作进行信创攻关，提高行业整体信创改造效率。
洪烨 技术专家：
全面信创是未来金融行业大部分企业的最终目标，从当前架构现状前往目标的路线，以及信创过程中的主要风险点，是当前阶段需要考虑的主要问题。
套用一句官方的说辞：当前国际形势严峻，面对监管机构的要求，对于金融行业的国企央企而言，不是是否需要全面信创的问题，而是如何全面信创的问题。有了这个终局的判断，从当前位置前进的方向也就相对清晰很多。但目前诸多企业又正在技术转型的过程中，全栈云、容器化都在各个项目中逐步落地，IT架构转型叠加基础架构调整，复杂的变化会让架构师和决策者不得不更谨慎地抉择。
面对如此复杂的问题，可以将其分解，逐类进行分析。当前金融企业通常将IT系统按照重要等级和影响性分为ABC三个等级，A类系统通常代表全局影响性系统，当A类系统发生故障时，会导致绝大部分交易受到影响。B类系统通常代表局部影响性系统，当B类型发生故障时，部分交易受到影响或某些渠道无法对外提供服务。C类系统通常代表内部系统或风险较低的系统，当C类系统发生故障，对外服务影响较低或无影响。而按照建设阶段来区分，我们又可以将系统分为新建系统及已上线系统。通过这两个维度的划分，可以得到A1-C2等六个维度（表1）。
表1：金融企业IT系统建设阶段分类
其中，C2是可以最先进行尝试的系统，业务风险等级低，系统架构简单，且没有遗留的历史包袱。可以优先在C2类系统进行架构尝试，熟悉新技术以及培养团队。但接下来会面临两个方向的选择。一是按照C2->C1->B2->B1->A2的顺序进行替换，这条路线见效快，但是难度大，有可能面临当前代码已无人维护等历史遗留问题。另一种是按照先新建再存量的顺序，风险低但除非赶上新核心建设这种历史阶段，否则信创替换的进度也会较低。
接下来谈下信创过程中需要评估的技术重点。目前信创的关键组件为CPU及数据库。CPU向信创迁移主要面临两个问题：一是兼容性的问题，之前大部分应用都是基于X86架构进行开发，如迁移到ARM架构的服务器，需要评估是否兼容，以及代码的改动成本，如果是同样X86的架构则无需考虑此问题；第二点是需要评估算力下降带来的影响，基于目前的一些经验来看，信创CPU比同样核数Intel的CPU算力要下降30%左右，如果是迁移系统，需要做好资源的预留考虑。
目前信创数据库主要分为集中式及分布式两类，当前在金融行业的ABC类系统中，都有在生产环境上线的成功案例，已经足以证明当前国内的数据库具备可以承载高并发及关键业务的能力。但需要特别注意的是，由于分布式与集中式的架构不同，为了达到更好的性能表现，在表设计、SQL使用、并发及隔离级别的使用上，都需要进行额外的考虑。尽量避免由于分片不当或者SQL访问不当导致过多的网络时延消耗以及并发冲突。
另外，还需要评估由于基础软件替换带来的兼容性及使用方式的影响。兼容性包含代码兼容性、功能兼容性以及数据存储类型的兼容性，需要重点进行逐项评估。使用方式主要是开发工具、开发习惯的一些使用，如果缺乏相关工具，也需进行补充或建设。
在当前的趋势及外部环境背景下，信创转型已经是各个企业需要提上日程的工作，在过程中的复杂程度、工作量及投入成本也往往令人却步。大部分系统的信创迁移，并不涉及到系统整体架构的调整，无形中也稍稍减少了信创替代工作带来的难度和挑战。值得欣慰的是，已有部分企业已经提供了比较成功的案例和相对成熟的路径，也给后续的信创替代之路指明了方向。
结束语
通过若干金融企业切身体会之总结，基本上我们对本议题的疑问有了基本共识，并且有了清晰的思路。正所谓“结合自身业务，在保障既有安全稳定的前提下，高处着眼低处着手”之观点。
