金融业务与服务的发展，是利用信息化技术持续改进与发展的过程，已有近30年的历程，这一发展过程的各个阶段，对于IT技术的定位与要求完全不同，这也是技术人员在不同阶段需要面对的问题与工作目标。

根据信息化技术在金融业务发展过程中所起到的作用，以及金融业务服务的阶段性特征，大体可分为三个阶段，各阶段之间，既有继承衔接的关系，也有并行发展的关系：

金融行业在二十多年以前，开始以计算机技术，逐步替代传统金融业务中的标准人工处理流程，主要包括会计核算、清结算等业务流程。金融业务的服务则仍以物理网点为主。

但随着计算机网络技术的发展，逐步开始提供跨网点、跨地域、跨银行的便捷金融服务，通过将金融业务人工流程计算机化，逐步提升了业务处理效率，降低了人为操作风险。

这一时期技术对于业务发展的关键作用与自身问题如下：

随着电子银行业务与技术的发展，逐步出现了以线上支付为基础的各类线上资金交易以及衍生金融服务。这类业务的特点是7*24小时、365天提供服务，并且提供各类跨机构的三方中间业务服务等。

服务流程跨度大复杂度高，为客户提供了更多的便利，金融业务开始逐步由线下物理网点转移到了线上各类渠道。

随着信息技术对于这种业务模式的实现与运行，逐步显现出两类关键问题：

随着金融服务需求的发展，以及各类资产的数字化，自然人与法人证照的数字化，这些数字资产交易的基础条件逐步成熟。

线上化的数字资产交易与服务业务，也将逐步进入成熟期，例如线上化的新车交易等，这类业务的实现，依托于如下两类信息技术的成熟与应用：

随着银行业务模式的持续发展，IT基础架构也在不断的丰富与发展，从基础的核心账务类系统，逐步衍生出线上业务渠道类、业务公共平台类、数据仓库分析类、非金融交易保障类等等。这些类型的系统架构，因其用户使用方式、数据流程、可靠与可用性要求等不同，系统架构的设计原则与需求不同，因此需要差异化设计，并针对不同类别的业务设定不同的架构发展路径。

上述各类业务场景下的系统架构所带来的系统架构模式，各自均需持续优化与发展，虽然各类模式的发展目标不同，但互相之间需要充分考虑衔接与集成的关系。

基于不同类别场景的系统架构设计，对其支撑的基础架构更需按“最小完备集”原则来分层分区设计，以便能够完整且灵活的支撑不同业务系统架构的实现，同时还能够保障满足监管审计、数据安全、容错容灾等银行业特定需求。

银行技术部门，虽然主要工作目标是支撑业务发展，但因金融业务与IT技术的密切关系，也需针对未来业务的发展预先设计基础的系统架构，并且能够结合当前的业务需求，例如目前线上信贷业务所需的影像资料等。

银行核心业务系统，因业务发展的周期性，也将周期性的实施改造或重新开发建设。每家银行因业务模式与重点存在差异，更换银行核心系统的业务需求与建设目标差异也较大，在此不做讨论。

但每次更换银行核心系统，也是一次整体的应用架构、数据架构、系统架构、运维架构的全面优化更新过程，这些架构的优化更新，一定是有的放矢，那么这个“的”是什么？是否准确？这就非常重要。

结合自身的工作经验，这些改进的目标，一定是从以往的实践和经验中得来，对于以往工作中的各类事件与问题，都需要详细的登记、分类、统计、分析，从中找出成因，设计解决方案，这样才能够保证每次核心系统更新与系统架构优化，能够真正的解决问题、支撑业务发展。

早期银行核心系统及其基础架构，仍然是以线下为主、线上为辅的模式为设计基础。但随着着金融行业业务模式的持续变化，当前已经是以线上为主、线下为辅的模式，对于原有的系统基础架构也必然带来一系列挑战。这些挑战往往很难在原有架构上解决，因此需要在系统架构整体改造过程中，予以重点解决。

例如，线上交易的强震荡性，也就是典型的秒杀模式，必然要求系统的业务通道为多活且可动态扩展的模式，但因为所有交易不可能都是同步模式，如何实现业务渠道多活并可动态扩展，就将带来异步交易的落地数据一致性问题。

在原有系统架构中，一般通过网络共享文件系统解决，但是因此会造成网络流量中，交易报文、数据文件传输、数据文件读写等类流量的资源竞争与互锁，严重影响系统整体可用性。

在新核心系统与系统架构改造过程中，针对此类问题，我们采取了服务器分角色规划设计，并针对需要承担共享数据类型的服务器，按网络多平面策略配置网络区域与网卡，实现各类流量分类分流，不但解决了整体可用性问题，还简化了安全防护的实施。

上述例子，只是系统基础架构改造的一个很小的局部例子。但每个局部的小改造，最终积累后，将能够比较有效的解决以往系统架构的系统性问题，这就是系统架构的逐渐变迁。

同时为了提高资源动态调配能力、降低整体使用成本，系统整体架构也逐步从烟囱状独享模式，演化为按功能分层、层级间共享的模式，提高了系统的标准化与自动化程度。

然而，事务往往是具有两面性的，这种模式的确具有明显的优点，但同时自身也存在弱点，也就是当某一层出现故障后，波及的范围会更大，并且对故障的监控定位也更难以实施。

所以在系统架构优化的同时，必须清醒地认识到某一架构设计的弱点，并配置必要的防护与解决措施，做到扬长避短，让系统架构能够更好地服务于业务，这也是系统架构可靠性设计的基本原则。

上文说到，系统架构层级化、集约化改造后，必然会带来某一层级出现故障后，波及范围扩大、破坏性增强的后果。因此针对架构改造的弱点，其中一项重点工作就是同步改造整体监控体系，以及必要的容错容灾与应急机制。

监控是容错容灾的基础，在后续章节将专门论述，在此简要介绍容错容灾与应急机制。

这里的容错，是指针对发生概率较高、破坏性较大的故障所采取的措施。例如SAN存储资源故障，可能造成部分应用系统数据库服务器的故障。此种情况下，因HA机制也是建立在SAN存储资源上的，自然无法发挥作用。并且因为涉及应用系统较少，如果采取同城容灾中心切换的话，将对整体服务产生较大影响，因此需要预先针对这种场景，设置例如克隆数据库加以保护。当出现此种问题后，就将应用系统快速切换到克隆数据库恢复服务。

这些基础环境的实施、应用系统的改造、风险事件的发现与识别、授权并启动应急流程、处置后的验证与问题总结，就是日常科技工作管理的核心内容，需要在工作目标、资源配置、操作流程、工具开发、演练评估、迭代优化等方面形成固定机制。

随着金融业务越来越复杂，以及业务渠道的多样化与线上化，金融业务产生的各类数据，其形式与复杂度都在大幅变化。

例如传统金融服务并不存在的非结构化数据、各类业务渠道数据的映射关系、数据标签化与主题分类等需求……这些业务数据管理与使用方面的变化，使得金融监管对于金融数据的要求也越来越高。

在新核心与配套系统架构设计过程中，业务数据全生命周期管理，也是一项重点工作。通过完整的业务数据全生命周期管理，不仅仅能够满足业务、监管、风控等方面的需求，还能提升系统性能、降低系统数据承载成本等。

• 业务数据全生命周期管理示意图：

针对银行金融服务的发展趋势，预先在资产数字化与数字资产交易领域进行研究与整体规划，并结合当前实际系统架构需求。例如非结构化数据管理与服务、身份识别、三方司法存证等服务需求，分阶段实施与改进。

• 业务创新支持整体架构设计示意图：

• 线上办公与业务实施架构分步改造图：

• 非结构化数据管理与数字资产基础功能列表：

现阶段各类数字化金融服务快速发展，也是各家银行业务竞争最激烈的领域之一。各银行基本都已经利用信息化技术，实现了各类线上的资产类、负债类、营销类业务。

技术作为业务发展的关键支撑能力之一，是要能够实现技术对于业务形成竞争优势的保障能力，其中最重要的是如何保证应用服务的整体质量，如何有效化解效率与质量的矛盾。

回顾银行IT技术与管理的发展历程：从研发与运维不分，到研发运维分离，再到因应用开发与投产衔接问题而带来的研发运维一体化改造，表面看是合久必分，分久必合的过程，其实是随着技术与经验的进步，已经逐步理清了将复杂问题进行有效分解，能够化繁为简的思路。

针对每个被细分的技术领域，实施有效的管理措施与技术规范，并且根据这个过程各个阶段的特点，将其落实到需求分析、方案设计、代码开发、测试验证、投产评估、变更控制、运维保障的各个阶段。在每个阶段，均根据阶段的不同目标，设定针对性很强的差异化技术规范与管理要求，以此种方式，最终解决系统建设效率与质量的矛盾问题。

之所以叫做应用系统，而不是应用程序，是因为一套业务系统的整体构成，除了基本的程序代码之外，还包括它的基础环境、网络通路、数据结构、安全防控、监控策略、计划作业等构件。

只有这些这些构件都能够正常运转，一套应用系统才能够很好的服务于业务。因此一套应用系统的服务效能，是基于应用系统架构、系统基础架构的可靠性设计实施基础之上的可用性管理过程：

• 可靠性设计：让应用系统的各个关节构件出现故障的情况下，从基本条件方面，具备可选择的退路。

• 可用性管理：是让这些可选择的退路能够在对应故障场景下，有效发挥作用。例如针对某一应用系统的数据库服务，设计并实施了克隆数据库保护，那么就要具备监测这套应用系统数据库故障的能力，并且能够识别并定位哪种故障是可以靠切换克隆库予以规避的，具体切换流程的标准化与自动化控制当然也需同步实施。

如上一章节讨论，应用系统是由应用程序及其所依赖的各个构件构成的。应用系统开发与投产质量控制的全过程，一定是针对不同构件在不同阶段的分别控制与设计实现，最终将这个应用系统的各个构件，按照化繁为简的思路，拆分成相对应的标准化与工具化的可维护性工作底稿，用于后续的各类技术实现控制。

上述可维护性工作底稿的最终形成，一定是一个过程，而不是一个点。这个过程需要需求、设计、开发、测试、投产、变更、运行各个环节的共同配合与协作，才能形成迭代优化的闭环管理过程，持续提升应用系统质量、提高应用系统的开发产能。

同时在每个工作环节中，需要将工作目标自上而下细分，细分到可标准化的程度。

例如提高应用系统可用性，是一个比较宏观比较笼统的目标，很难标准化。但是如果细分到：按照操作系统配置模板，逐项检查系统核心参数；按照标准监控策略，逐项核对是否部署监控工具，就是可标准化，甚至是可自动化的子目标。

因此在这里借用了工业化生产中始终坚持的“工艺管理”这个概念，通过细分与精细化实施，真正秉持工匠精神，做到精益求精，而不是只关注新技术新产品的堆砌，不关注最终的使用效果。采用一种新技术新产品，一定是有的放矢、目标明确，并且要用透用好。

研发与运维共同配合，完成了应用系统的开发与投产，仅仅是万里长征第一步。

一套应用系统服务于具体业务，是一个全生命周期的服务过程。期间应用系统的具体运行效能，一定要具备持续运营服务的能力。

这里既包括最基础的运维监控，也包括业务数据服务、业务运营支持服务等方面的工作。其中，运维监控是最基础也是最核心的内容。以往我们讨论运维监控，其实没有真正的分清楚监与控的区别及关联，以及支撑监与控能力所需的基础运维管理工作。

如何让运维监控工作真正发挥作用？

通过实践证明，以结果为导向，自上而下、层层细化，是比较有效的方法。例如，针对各类故障，能够监控发现哪些、未能发现哪些？监控的漏洞是什么？如何修补？为什么出现了漏洞？是应用系统的构件被遗漏了，还是针对构件是否正常的判断策略不完备？

简要总结这个思路过程如下：

以监控结果为导向，评估监控的效果，尤其重点针对未能发现的故障。从监控对象漏洞，监控策略不足等角度分析，并融入到日常工作，形成固定工作机制，逐步提升监控效能。

监视和控制是运维监控工作的两个部分，是互相独立但又互相衔接的过程。

首先要能做到发现，在发现之后能够定位，能够确定具体是哪一故障场景。然后才是根据具体场景，采用标准化的处置方式，规避故障，尽快恢复业务服务。这里强调的是规避故障，而不是彻底解决故障。

例如消息队列拥堵，首先采取队列清理与重启操作恢复服务，而不是排查应用系统是如何造成拥堵的。

同时，因为银行应用系统，很多都是365天24小时运行，很难保证发生故障的情况时各类专业技术人员都在场。因此，24小时值机ECC人员的操作标准化程度与训练水平，就是监控结果的最终体现。

抛开五花八门的监控工具不讲，首先要将发现、定位、处理、验证操作标准化，哪怕每个过程是人工操作的模式，只要有效就达到了目。在此基础上，再去实施工具化，自然是水到渠成的。

运维监控的基础工作，是能够完整的拆分应用系统，形成针对各个构件的一套完备的监控指标集，并根据具体情况与技术特点，选择合适的监控工具，这是运维监控效能分析与持续优化的工作基础。

银行科技工作的最终目标，是服务于业务、服务于客户，所以打造一套能够前后台有效衔接、能够持续自我完善的科技运营服务体系至关重要。

科技运营服务体系，是一套自下而上、层层衔接、由技术到服务的体系。每个层级的目标不同、重点不同，但需要通过技术与管理有效衔接，才能形成有效的、优质的服务体系，并且能够持续的从服务中发现问题，改进前后台建设策略。

科技运营服务体系的支撑，需要依靠完备的后台基础，并且在后台基础的设计与维护工程中，需要始终坚持为前台服务的思想。

在各技术领域的设计与实现过程中做到标准化及有效衔接，这是业务“工艺”思想的体现，依托此思想，才能够生产出质量优良的产品。

有了可靠且标准化的后台服务基础后，还需要有一套标准化程度高、可持续维护的科技运营服务目录支撑，并以此为基础，来确保前后台服务的一致性与精确性。

这种模式是与传统纯粹人工管理模式的最大差异。如果只是简单引入服务台工具，却没有一套完备的科技运维服务目录支撑，那就仅仅是将人工管理稍作改进而已。

科技运营服务的最终体现，是前台对于银行业务人员、银行直接客户的服务。具备了完备的科技运营管理体系、完善的后台基础配置以及动态更新的科技运营服务目录后，还需具备一套“贴身”服务的工具组合、工作机制、服务交付、服务改进的前端服务体系。

只有这样，才能够实现前后台的有效衔接，促进一个能够持续自我完善的科技运营服务体系的落地，并更好地服务于银行的业务。

获取本期PPT

请添加右侧二维码微信