01. 銀行業(yè)數(shù)字化轉(zhuǎn)型白皮書（2023）對研運(yùn)能力建設(shè)的啟發(fā)

近日，中國工商銀行與中國信通院聯(lián)合編制了業(yè)界首份《銀行業(yè)數(shù)字化轉(zhuǎn)型白皮書(2023)》，對銀行業(yè)的數(shù)字化轉(zhuǎn)型進(jìn)行系統(tǒng)剖析，提出了銀行業(yè)數(shù)字化轉(zhuǎn)型的基本方法、實(shí)施路徑、發(fā)展趨勢。

1）銀行業(yè)數(shù)字化轉(zhuǎn)型路徑

白皮書指出銀行業(yè)數(shù)字化轉(zhuǎn)型應(yīng)從頂層設(shè)計(jì)、模式創(chuàng)新、科技賦能三個(gè)方面進(jìn)行建設(shè)，其中IT相關(guān)的科技賦能包括數(shù)據(jù)治理與賦能、數(shù)字技術(shù)能力建設(shè)與應(yīng)用兩個(gè)領(lǐng)域，要求通過多層級強(qiáng)化數(shù)據(jù)要素創(chuàng)新應(yīng)用，多領(lǐng)域深化數(shù)字技術(shù)服務(wù)供給，多維度進(jìn)化數(shù)字基礎(chǔ)設(shè)施支撐，筑牢轉(zhuǎn)型發(fā)展根基。在數(shù)字技術(shù)服務(wù)供給和數(shù)字基礎(chǔ)設(shè)施支撐方面對研運(yùn)能力提出了對應(yīng)的建設(shè)建議。

2）多領(lǐng)域深化數(shù)字技術(shù)服務(wù)供給能力

建設(shè)基礎(chǔ)技術(shù)體系。基礎(chǔ)技術(shù)體系為銀行提供基礎(chǔ)的計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)以及企業(yè)級研發(fā)、運(yùn)行、運(yùn)維服務(wù)，是銀行的數(shù)字基礎(chǔ)設(shè)施。銀行業(yè)積極運(yùn)用云計(jì)算、分布式技術(shù)打造開放化基礎(chǔ)技術(shù)架構(gòu)，推進(jìn)業(yè)務(wù)下主機(jī)，有效支撐業(yè)務(wù)快速增長和大數(shù)據(jù)創(chuàng)新應(yīng)用。具體如下表1：

3）多維度進(jìn)化數(shù)字基礎(chǔ)設(shè)施支撐能力

開展系統(tǒng)架構(gòu)轉(zhuǎn)型。互聯(lián)網(wǎng)發(fā)展及大數(shù)據(jù)應(yīng)用對算力提出更高需求，銀行積極推進(jìn)云計(jì)算平臺建設(shè)、分布式架構(gòu)轉(zhuǎn)型。具體如下表2：

從以上的建設(shè)要求來看，隨著銀行數(shù)字化轉(zhuǎn)型和新核心建設(shè)的推進(jìn)，對研運(yùn)能力的要求也進(jìn)一步提升，一是對云原生、分布式架構(gòu)的適配支持，二是對研運(yùn)工作線上化、一體化的打通，三是對生產(chǎn)安全保障能力的體系化要求。

銀行數(shù)字化轉(zhuǎn)型及其對IT能力的要求是銀行IT從業(yè)者關(guān)注的重要問題。IT團(tuán)隊(duì)?wèi)?yīng)該做什么？怎么做？怎么衡量建設(shè)效果？監(jiān)管機(jī)構(gòu)、行業(yè)協(xié)會(huì)以及銀行數(shù)字化轉(zhuǎn)型先行者都給出了一些指引及參考借鑒，部分重要內(nèi)容如下：

1. 《中國銀保監(jiān)會(huì)辦公廳關(guān)于銀行業(yè)保險(xiǎn)業(yè)數(shù)字化轉(zhuǎn)型的指導(dǎo)意見》：銀保監(jiān)會(huì)2022年1月發(fā)布
2. 《JR/T 0271—2023 金融數(shù)字化能力成熟度指引》：中國人民銀行2023年11月發(fā)布
3. 《銀行業(yè)數(shù)字化轉(zhuǎn)型白皮書（2023）》：工商銀行、中國信通院2023年12月28日聯(lián)合發(fā)布
4. 《基于業(yè)務(wù)價(jià)值的金融業(yè)數(shù)字化轉(zhuǎn)型能力評估模型》：中國信通院2023年12月發(fā)布
5. 《商業(yè)銀行“Bank Digital Mesh”數(shù)字化成熟度評估模型白皮書》：百信銀行2023年2月發(fā)布

02. 各建設(shè)指引對研運(yùn)建設(shè)的要求及建議

通過各文件的分析對比（其中《《基于業(yè)務(wù)價(jià)值的金融業(yè)數(shù)字化轉(zhuǎn)型能力評估模型》僅有模型框架圖），可以發(fā)現(xiàn)《商業(yè)銀行“Bank Digital Mesh”數(shù)字化成熟度評估模型白皮書》主要從云計(jì)算和敏捷交付層面提了偏泛化的要求，其他的指導(dǎo)意見、建設(shè)指引有涉及研發(fā)運(yùn)維具體的能力、工具建設(shè)。綜合來看，銀行業(yè)數(shù)字化轉(zhuǎn)型背景下的IT建設(shè)，在研發(fā)領(lǐng)域，強(qiáng)調(diào)敏捷轉(zhuǎn)型，建設(shè)研發(fā)運(yùn)維一體化工具，提升交付效率和質(zhì)量；在運(yùn)維領(lǐng)域，強(qiáng)調(diào)安全生產(chǎn)，構(gòu)建集中監(jiān)控能力，建設(shè)自動(dòng)化運(yùn)維體系，通過運(yùn)維數(shù)據(jù)治理和算法的應(yīng)用提升智能運(yùn)維水平，其中工商銀行發(fā)布的白皮書明確指出運(yùn)維核心能力包括運(yùn)維基礎(chǔ)技術(shù)支撐、持續(xù)交付、 監(jiān)控分析、應(yīng)急處置、性能容量、變更風(fēng)險(xiǎn)管控。

以上對IT能力的要求實(shí)際是在要求研運(yùn)過程的數(shù)字化，數(shù)字化的本質(zhì)是通過數(shù)據(jù)的自動(dòng)流動(dòng)來化解復(fù)雜系統(tǒng)的不確定性。通過建設(shè)IT團(tuán)隊(duì)的數(shù)字化工作空間，將人機(jī)交互、人人交互的過程數(shù)據(jù)化，讓研運(yùn)數(shù)據(jù)的自動(dòng)流動(dòng)和消費(fèi)，可以助力工作的協(xié)同、度量和改進(jìn)，通過研運(yùn)數(shù)字化來助力業(yè)務(wù)數(shù)字化。這需要足夠好的工具體系來承載企業(yè)的研運(yùn)工作。

由于傳統(tǒng)建設(shè)模式會(huì)讓企業(yè)存在較多孤島式的研運(yùn)工具，這些孤島阻礙了研運(yùn)數(shù)據(jù)的流動(dòng)，因此需要依循新的工作流程從工具層面打通整個(gè)協(xié)同過程。借鑒業(yè)務(wù)中臺建設(shè)的方式進(jìn)行研運(yùn)中臺建設(shè)，一是構(gòu)建能力底座，將通用研運(yùn)能力服務(wù)化；二是基于長期價(jià)值考慮，集成或替換現(xiàn)有工具融入中臺，實(shí)現(xiàn)數(shù)據(jù)和能力的打通；三是通過低代碼運(yùn)維開發(fā)手段或者流程編排引擎做場景構(gòu)建，支持變更管控、容量分析等場景。

03. 研運(yùn)數(shù)字化建設(shè)思路

由于研運(yùn)工作本身的復(fù)雜性，通過某一個(gè)或某幾個(gè)產(chǎn)品來覆蓋整個(gè)研運(yùn)工作實(shí)際上是不限時(shí)的，實(shí)現(xiàn)研發(fā)運(yùn)維的一體化并不是換一個(gè)產(chǎn)品，而是換一種建設(shè)方式。就如同業(yè)務(wù)系統(tǒng)從單體到SOA到微服務(wù)的發(fā)展，研發(fā)運(yùn)維的一體化打破煙囪的方式是連接整合，而不是徹底統(tǒng)一。而在研發(fā)運(yùn)維這樣的支撐領(lǐng)域，必定難以像業(yè)務(wù)系統(tǒng)一樣投入大量的資源做完全的微服務(wù)改造，研發(fā)運(yùn)維一體化更傾向于SOA和微服務(wù)結(jié)合的模式，通過ESB或者API網(wǎng)關(guān)打通各個(gè)軟件系統(tǒng)，非核心工具系統(tǒng)只需要提供API和數(shù)據(jù)，部分核心模塊如CMDB則可進(jìn)行微服務(wù)改造。

通過連接的方式促進(jìn)研發(fā)運(yùn)維一體化建設(shè)可以分為三個(gè)方面，數(shù)據(jù)的連接、執(zhí)行能力的連接和場景的構(gòu)建。

1）研運(yùn)數(shù)據(jù)治理

要實(shí)現(xiàn)數(shù)據(jù)的連接，需要進(jìn)行研運(yùn)數(shù)據(jù)的治理，首先需要各個(gè)模塊有統(tǒng)一的元數(shù)據(jù)，比如說可以基于同一個(gè)CMDB做數(shù)據(jù)轉(zhuǎn)化，只有能夠識別出同樣的IT對象，數(shù)據(jù)與數(shù)據(jù)之間才可能產(chǎn)生連接。

其次需要可以統(tǒng)一調(diào)用的數(shù)據(jù)資源池，將各系統(tǒng)的數(shù)據(jù)做匯聚。這種數(shù)據(jù)的匯聚可以有兩種方法，高階的做法是做統(tǒng)一的數(shù)據(jù)存儲(chǔ)，這種做法技術(shù)難度高，成本大，但有利于后續(xù)運(yùn)維大數(shù)據(jù)和AIOps的建設(shè)。變通的做法是做查詢接口的統(tǒng)一管理，基于API或者數(shù)據(jù)庫讀取的方式獲取數(shù)據(jù)，一般用于報(bào)表編輯或者其他系統(tǒng)的集成開發(fā)，這種做法相對簡易，但是不利于場景的擴(kuò)展。

2）研運(yùn)能力治理

執(zhí)行能力的連接，主要實(shí)現(xiàn)方式是對各工具模塊的API做統(tǒng)一管控。通過ESB或者API網(wǎng)關(guān)的方式將不同工具模塊的核心執(zhí)行能力做管理，并供其他模塊進(jìn)行消費(fèi)。

研運(yùn)能力治理的難點(diǎn)在于存量的研運(yùn)工具對外暴露的能力一般而言不會(huì)非常完整，如果需要做API開發(fā)的話需要投入不少資源做改造。在進(jìn)行運(yùn)維能力治理時(shí)需要有所取舍，舍棄封閉性較強(qiáng)的運(yùn)維系統(tǒng)，盡量替換成開放性高，具有良好生態(tài)的研運(yùn)系統(tǒng)，并且在進(jìn)行API開發(fā)時(shí)遵循“二八原則”，在資源有限的情況下只對需要經(jīng)常調(diào)用的能力做API開發(fā)，保障投入產(chǎn)出比。

3）通過編排進(jìn)行場景構(gòu)建

當(dāng)把各工具模塊的數(shù)據(jù)和能力連接到一起，并構(gòu)成了研運(yùn)中臺能力之后，下一步就是基于這些豐富的素材通過編排的方式做研運(yùn)場景的優(yōu)化。編排的方式有四種：執(zhí)行流程編排（自動(dòng)化）、數(shù)據(jù)編排、管理流程編排、研運(yùn)場景編排。

① 執(zhí)行流程編排

執(zhí)行流程編排即針對自動(dòng)化能力的編排，將針對操作系統(tǒng)的腳本、平臺工作的API作為執(zhí)行原子將企業(yè)內(nèi)部多系統(tǒng)間的工作整合到一個(gè)流程模版中，實(shí)現(xiàn)一鍵自動(dòng)化調(diào)度。通過執(zhí)行流程編排可以對構(gòu)建測試、投產(chǎn)發(fā)布、故障恢復(fù)等作業(yè)進(jìn)行封裝管理。

② 數(shù)據(jù)編排

數(shù)據(jù)編排即針對數(shù)據(jù)的可視化編排，作為研運(yùn)領(lǐng)域的BI，從各個(gè)工具模塊或IT對象中消費(fèi)數(shù)據(jù)通過報(bào)表的方式做可視化呈現(xiàn)，實(shí)現(xiàn)研運(yùn)工作的統(tǒng)計(jì)分析。一般可用于研發(fā)效能、IT服務(wù)乃至于人員績效的度量。

③ 管理流程編排

管理流程編排即針對ITSM流程的編排，在流程引擎（可支持審批、會(huì)簽、分支等基本流程需求）的基礎(chǔ)上還需結(jié)合執(zhí)行流程編排、報(bào)表編排的功能，實(shí)現(xiàn)審批流、操作流、數(shù)據(jù)流的融合。一般用于需求管理、缺陷管理、投產(chǎn)發(fā)布、事件問題變更等管理工作。

④ 研運(yùn)場景編排

研運(yùn)場景編排是在數(shù)據(jù)治理、能力治理基礎(chǔ)上的高階應(yīng)用，通過低代碼的方式基于已整合的數(shù)據(jù)和API做融合性運(yùn)維工具的開發(fā)。執(zhí)行流程編排、報(bào)表編排、管理流程編排會(huì)作為低代碼開發(fā)的能力項(xiàng)使用。研運(yùn)場景編排的低代碼能力可以更快速地進(jìn)行研運(yùn)數(shù)字化的覆蓋。

最后，歡迎隨時(shí)與嘉為藍(lán)鯨共同探討！