01. 银行业数字化转型白皮书（2023）对研运能力建设的启发
近日，中国工商银行与中国信通院联合编制了业界首份《银行业数字化转型白皮书(2023)》，对银行业的数字化转型进行系统剖析，提出了银行业数字化转型的基本方法、实施路径、发展趋势。
1）银行业数字化转型路径
白皮书指出银行业数字化转型应从顶层设计、模式创新、科技赋能三个方面进行建设，其中IT相关的科技赋能包括数据治理与赋能、数字技术能力建设与应用两个领域，要求通过多层级强化数据要素创新应用，多领域深化数字技术服务供给，多维度进化数字基础设施支撑，筑牢转型发展根基。在数字技术服务供给和数字基础设施支撑方面对研运能力提出了对应的建设建议。
2）多领域深化数字技术服务供给能力
建设基础技术体系。基础技术体系为银行提供基础的计算、存储、网络以及企业级研发、运行、运维服务，是银行的数字基础设施。银行业积极运用云计算、分布式技术打造开放化基础技术架构，推进业务下主机，有效支撑业务快速增长和大数据创新应用。具体如下表1：
3）多维度进化数字基础设施支撑能力
开展系统架构转型。互联网发展及大数据应用对算力提出更高需求，银行积极推进云计算平台建设、分布式架构转型。具体如下表2：
从以上的建设要求来看，随着银行数字化转型和新核心建设的推进，对研运能力的要求也进一步提升，一是对云原生、分布式架构的适配支持，二是对研运工作线上化、一体化的打通，三是对生产安全保障能力的体系化要求。
银行数字化转型及其对IT能力的要求是银行IT从业者关注的重要问题。IT团队应该做什么？怎么做？怎么衡量建设效果？监管机构、行业协会以及银行数字化转型先行者都给出了一些指引及参考借鉴，部分重要内容如下：
- 《中国银保监会办公厅关于银行业保险业数字化转型的指导意见》：银保监会2022年1月发布
- 《JR/T 0271—2023 金融数字化能力成熟度指引》：中国人民银行2023年11月发布
- 《银行业数字化转型白皮书（2023）》：工商银行、中国信通院2023年12月28日联合发布
- 《基于业务价值的金融业数字化转型能力评估模型》：中国信通院2023年12月发布
- 《商业银行“Bank Digital Mesh”数字化成熟度评估模型白皮书》：百信银行2023年2月发布
02. 各建设指引对研运建设的要求及建议
通过各文件的分析对比（其中《《基于业务价值的金融业数字化转型能力评估模型》仅有模型框架图），可以发现《商业银行“Bank Digital Mesh”数字化成熟度评估模型白皮书》主要从云计算和敏捷交付层面提了偏泛化的要求，其他的指导意见、建设指引有涉及研发运维具体的能力、工具建设。综合来看，银行业数字化转型背景下的IT建设，在研发领域，强调敏捷转型，建设研发运维一体化工具，提升交付效率和质量；在运维领域，强调安全生产，构建集中监控能力，建设自动化运维体系，通过运维数据治理和算法的应用提升智能运维水平，其中工商银行发布的白皮书明确指出运维核心能力包括运维基础技术支撑、持续交付、 监控分析、应急处置、性能容量、变更风险管控。
以上对IT能力的要求实际是在要求研运过程的数字化，数字化的本质是通过数据的自动流动来化解复杂系统的不确定性。通过建设IT团队的数字化工作空间，将人机交互、人人交互的过程数据化，让研运数据的自动流动和消费，可以助力工作的协同、度量和改进，通过研运数字化来助力业务数字化。这需要足够好的工具体系来承载企业的研运工作。
由于传统建设模式会让企业存在较多孤岛式的研运工具，这些孤岛阻碍了研运数据的流动，因此需要依循新的工作流程从工具层面打通整个协同过程。借鉴业务中台建设的方式进行研运中台建设，一是构建能力底座，将通用研运能力服务化；二是基于长期价值考虑，集成或替换现有工具融入中台，实现数据和能力的打通；三是通过低代码运维开发手段或者流程编排引擎做场景构建，支持变更管控、容量分析等场景。
03. 研运数字化建设思路
由于研运工作本身的复杂性，通过某一个或某几个产品来覆盖整个研运工作实际上是不限时的，实现研发运维的一体化并不是换一个产品，而是换一种建设方式。就如同业务系统从单体到SOA到微服务的发展，研发运维的一体化打破烟囱的方式是连接整合，而不是彻底统一。而在研发运维这样的支撑领域，必定难以像业务系统一样投入大量的资源做完全的微服务改造，研发运维一体化更倾向于SOA和微服务结合的模式，通过ESB或者API网关打通各个软件系统，非核心工具系统只需要提供API和数据，部分核心模块如CMDB则可进行微服务改造。
通过连接的方式促进研发运维一体化建设可以分为三个方面，数据的连接、执行能力的连接和场景的构建。
1）研运数据治理
要实现数据的连接，需要进行研运数据的治理，首先需要各个模块有统一的元数据，比如说可以基于同一个CMDB做数据转化，只有能够识别出同样的IT对象，数据与数据之间才可能产生连接。
其次需要可以统一调用的数据资源池，将各系统的数据做汇聚。这种数据的汇聚可以有两种方法，高阶的做法是做统一的数据存储，这种做法技术难度高，成本大，但有利于后续运维大数据和AIOps的建设。变通的做法是做查询接口的统一管理，基于API或者数据库读取的方式获取数据，一般用于报表编辑或者其他系统的集成开发，这种做法相对简易，但是不利于场景的扩展。
2）研运能力治理
执行能力的连接，主要实现方式是对各工具模块的API做统一管控。通过ESB或者API网关的方式将不同工具模块的核心执行能力做管理，并供其他模块进行消费。
研运能力治理的难点在于存量的研运工具对外暴露的能力一般而言不会非常完整，如果需要做API开发的话需要投入不少资源做改造。在进行运维能力治理时需要有所取舍，舍弃封闭性较强的运维系统，尽量替换成开放性高，具有良好生态的研运系统，并且在进行API开发时遵循“二八原则”，在资源有限的情况下只对需要经常调用的能力做API开发，保障投入产出比。
3）通过编排进行场景构建
当把各工具模块的数据和能力连接到一起，并构成了研运中台能力之后，下一步就是基于这些丰富的素材通过编排的方式做研运场景的优化。编排的方式有四种：执行流程编排（自动化）、数据编排、管理流程编排、研运场景编排。
① 执行流程编排
执行流程编排即针对自动化能力的编排，将针对操作系统的脚本、平台工作的API作为执行原子将企业内部多系统间的工作整合到一个流程模版中，实现一键自动化调度。通过执行流程编排可以对构建测试、投产发布、故障恢复等作业进行封装管理。
② 数据编排
数据编排即针对数据的可视化编排，作为研运领域的BI，从各个工具模块或IT对象中消费数据通过报表的方式做可视化呈现，实现研运工作的统计分析。一般可用于研发效能、IT服务乃至于人员绩效的度量。
③ 管理流程编排
管理流程编排即针对ITSM流程的编排，在流程引擎（可支持审批、会签、分支等基本流程需求）的基础上还需结合执行流程编排、报表编排的功能，实现审批流、操作流、数据流的融合。一般用于需求管理、缺陷管理、投产发布、事件问题变更等管理工作。
④ 研运场景编排
研运场景编排是在数据治理、能力治理基础上的高阶应用，通过低代码的方式基于已整合的数据和API做融合性运维工具的开发。执行流程编排、报表编排、管理流程编排会作为低代码开发的能力项使用。研运场景编排的低代码能力可以更快速地进行研运数字化的覆盖。
最后，欢迎随时与嘉为蓝鲸共同探讨！
