劉中華 孫科

摘要：傳統(tǒng)銀行在強(qiáng)監(jiān)管背景下，如何能夠在互聯(lián)網(wǎng)金融的沖擊下順利完成數(shù)字化轉(zhuǎn)型已成為各大銀行的首要任務(wù)，針對該問題本文通過介紹DevOps主要概念、分析DevOps的關(guān)鍵技術(shù)，提出了傳統(tǒng)銀行可以從團(tuán)隊(duì)及組織架構(gòu)、文化、流程、工具、平臺等多個(gè)維度進(jìn)行DevOps轉(zhuǎn)型實(shí)踐的思考，從而為傳統(tǒng)銀行的DevOps轉(zhuǎn)型提供參考。

關(guān)鍵詞：DevOps;銀行轉(zhuǎn)型;DevOps轉(zhuǎn)型;敏捷開發(fā);銀行數(shù)字化

中圖分類號：TP39 文獻(xiàn)標(biāo)識碼：A

文章編號：1009-3044（2020）29-0236-03

1 前言

伴隨著DevOps在全球各行業(yè)快速流行，DevOps已經(jīng)成為企業(yè)適應(yīng)市場和提升創(chuàng)新力的便捷之路，根據(jù)中國信息通信研究院2019年中國DevOps現(xiàn)狀調(diào)查得知：受訪者來自包括互聯(lián)網(wǎng)、科技、電信、制造等十多個(gè)行業(yè)，其中互聯(lián)網(wǎng)和科技占據(jù)半壁江山，從行業(yè)的分布可以看出，DevOps已經(jīng)逐步在各個(gè)行業(yè)落地實(shí)踐了。其中，超7成受訪者DevOps經(jīng)驗(yàn)少于1年，58%受訪者DevOps調(diào)研經(jīng)驗(yàn)小于半年，15%的受訪者DevOps經(jīng)驗(yàn)不到1年，25%的受訪者DevOps經(jīng)驗(yàn)大于1年[1]。此外，隨著“互聯(lián)網(wǎng)+金融”的飛速發(fā)展，傳統(tǒng)銀行面對數(shù)量越來越多的互聯(lián)網(wǎng)應(yīng)用種類也越來越多，對軟件的開發(fā)效率要求也越來越高，金融用戶脫媒趨勢已逐成定局，數(shù)據(jù)與市場脫媒方興未艾，在強(qiáng)監(jiān)管的要求下，傳統(tǒng)銀行也面臨著較大的危機(jī)，如何破局成為各大銀行的首要任務(wù)。

因此，敏捷和DevOps也逐漸進(jìn)入以合規(guī)和穩(wěn)健為主流文化的傳統(tǒng)銀行業(yè)，目前DevOps轉(zhuǎn)型在銀行業(yè)已成燎原之勢，中國銀行業(yè)敏捷轉(zhuǎn)型之大幕已經(jīng)拉開，“5+12”銀行（5家國有商業(yè)銀行+12家股份制銀行）都在大力推進(jìn)[21。根據(jù)中國信息通信研究院研究金牌運(yùn)維評估數(shù)據(jù)顯示，DevOps正遍地開花，在各種規(guī)模的企業(yè)中落地，截至2017年已有78%的企業(yè)使用開源的自動化運(yùn)維工具[3]。

2 DevOps概念

每當(dāng)提及DevOps是什么的時(shí)候，由于不限定人群和范圍，每個(gè)人都能從自己的立場來解讀DevOps，很多行業(yè)先行者給出的定義也常常不同，DevOps之父Patrick第一次參加Dev0-psDays中國站活動的時(shí)候，也使用“盲人摸象”比喻大家對De-vOps的認(rèn)識，因?yàn)镈evOps運(yùn)動從誕生起，DevOps文化一直在不斷發(fā)展和進(jìn)步，這些先行者們就從來沒有試圖給DevOps下一個(gè)官方的定義。

與其糾結(jié)于DevOps的定義，不如讓我們一起回歸原始，來看看DevOps究竟要解決的是什么問題。其實(shí)，DevOps的秘密就來源于它的名字所代表的兩種角色——開發(fā)（Development）和運(yùn)維（Operations）。那么這兩種角色之間究竟有什么問題呢？我們從軟件工程誕生以來所歷經(jīng)的三個(gè)重要發(fā)展階段說起。

第一階段：瀑布開發(fā)模式。瀑布式開發(fā)最初在1970年由W.W.Royce提出，它是一種老舊的計(jì)算機(jī)軟件開發(fā)方法。瀑布式嚴(yán)格遵循預(yù)先計(jì)劃的需求分析、設(shè)計(jì)、編碼、集成、測試、維護(hù)的步驟順序進(jìn)行，是一種最典型的預(yù)見性的方法。隨著市場環(huán)境和用戶需求變化的不斷加速，這種按部就班的方式有一個(gè)嚴(yán)重的問題，如果需求不明確或者在項(xiàng)目進(jìn)行過程中有可能發(fā)生變化的情況下使用瀑布式開發(fā)模型會導(dǎo)致其自由度降低，項(xiàng)目早期即作出承諾會導(dǎo)致對后期需求的變化難以調(diào)整。從業(yè)界巨頭IBM的統(tǒng)計(jì)數(shù)字來看，使用此開發(fā)模式有34%的IT項(xiàng)目延期交付，將近一半的應(yīng)用系統(tǒng)因?yàn)槿毕輰?dǎo)致線上回滾。

第二階段：敏捷迭代開發(fā)模式。為了彌補(bǔ)傳統(tǒng)開發(fā)模式的缺點(diǎn)，敏捷開發(fā)模式應(yīng)運(yùn)而生，它具有更高的成功率和生產(chǎn)率，也被稱作迭代增量式開發(fā)或迭代進(jìn)化式開發(fā)。在迭代開發(fā)模式中，項(xiàng)目組會將整個(gè)項(xiàng)目劃分為一系列的短小的、固定長度（如2周）的小項(xiàng)目也就是一個(gè)迭代周期，每一次迭代都包括了需求分析、設(shè)計(jì)、實(shí)現(xiàn)與測試。采用這種模式，開發(fā)工作是在需求被完整地確定之前啟動，并在一次迭代中完成系統(tǒng)的一部分相對完整的功能，然后通過客戶的反饋來細(xì)化需求，并開始新一輪的迭代。敏捷迭代開發(fā)模式看似每個(gè)迭代花費(fèi)了更多的時(shí)間，但是在每個(gè)迭代就讓用戶介入反饋確保其實(shí)施的正確性，節(jié)省了大量不必要的浪費(fèi)和返工。

第三階段：DevOps開發(fā)模式，敏捷迭代開發(fā)模式雖然解決了開發(fā)與測試快速協(xié)作問題，并使得開發(fā)和測試測試團(tuán)隊(duì)能夠抱團(tuán)取暖，可是問題又來了，開發(fā)和測試團(tuán)隊(duì)發(fā)現(xiàn)，不管研發(fā)的速度變得多快，在軟件交付的另一端，如果沒有經(jīng)過運(yùn)維環(huán)節(jié)的部署上線，并最終發(fā)布給真實(shí)用戶，那么這些功能其實(shí)并沒有什么用。在墻的另一端的運(yùn)維團(tuán)隊(duì)成了被拉攏的對象。這些在軟件交付最末端的團(tuán)隊(duì)始終處于一種“背鍋”的狀態(tài)，他們也有改變的意愿，所以DevOps應(yīng)運(yùn)而生，也就是說，DevOps最開始想要打破的就是開發(fā)和運(yùn)維之間的對立和隔閡。除此之外，運(yùn)維團(tuán)隊(duì)慢慢轉(zhuǎn)向運(yùn)營團(tuán)隊(duì)，他們持續(xù)不斷地把線上的真實(shí)數(shù)據(jù)和用戶行為及時(shí)地反饋給需求團(tuán)隊(duì)，來幫助需求團(tuán)隊(duì)客觀評估需求的價(jià)值，并及時(shí)作出有利于產(chǎn)品發(fā)展的調(diào)整，很快業(yè)務(wù)部門被引入到DevOps之中。除此之外，系統(tǒng)上線后安全成為系統(tǒng)必須解決的問題，在每個(gè)過程中會注入安全反饋機(jī)制，來幫助團(tuán)隊(duì)在第一時(shí)間應(yīng)對安全風(fēng)險(xiǎn)，那么，安全團(tuán)隊(duì)也有加入DevOps的需求。這樣的例子比比皆是，包括職能部門、戰(zhàn)略部門等，都紛紛加入其中，使得DevOps由最開始的點(diǎn)，擴(kuò)展為線，再到面，不斷發(fā)展壯大。每個(gè)人都參與其中，這使得De-vOps成了每一個(gè)IT從業(yè)人員都需要學(xué)習(xí)和了解的知識和技能體系。DevOps代表了IT文化的變化，在面向系統(tǒng)全局（上下文）采用敏捷、精益實(shí)踐，關(guān)注于快速的IT服務(wù)交付。

因此，DevOps可以定義為（開發(fā)Development與運(yùn)維Oper-ations的組合詞）是一種文化、一場運(yùn)動或?qū)嵺`，強(qiáng)調(diào)在自動化軟件交付流程及基礎(chǔ)設(shè)施變更過程中，軟件開發(fā)人員與其他信息技術(shù)（測試、運(yùn)維、業(yè)務(wù)、安全、職能部門等）專業(yè)人員彼此之間的協(xié)作與溝通。它旨在建立一種文化與環(huán)境，使構(gòu)建、測試、軟件發(fā)布得以快速、頻繁以及更加穩(wěn)定地進(jìn)行。

3 DevOps的關(guān)鍵技術(shù)

在2017年底，由中國信息通信研究院云計(jì)算開源產(chǎn)業(yè)聯(lián)盟（OSCAR）聯(lián)合高效運(yùn)維社區(qū)、DevOps時(shí)代、騰訊、京東、浙江移動、中國銀行、中國電信、太平洋保險(xiǎn)集團(tuán)等行業(yè)頂級技術(shù)專家100多名，共同編寫制定了國內(nèi)外第一個(gè)DevOps系列標(biāo)準(zhǔn)——研發(fā)運(yùn)營能力一體化能力成熟度模型，該系列標(biāo)準(zhǔn)分為敏捷開發(fā)管理、持續(xù)交付、技術(shù)運(yùn)營、應(yīng)用設(shè)計(jì)、安全風(fēng)險(xiǎn)管理和組織結(jié)構(gòu)7個(gè)部分，涵蓋了全軟件的開發(fā)和運(yùn)維生命周期，這是行業(yè)智慧的結(jié)晶，也為構(gòu)建云時(shí)代下的新型軟件開發(fā)與運(yùn)營模式奠定堅(jiān)實(shí)的基礎(chǔ)[3]。在2018年9月份，該DevOps標(biāo)準(zhǔn)已在聯(lián)合國直屬標(biāo)準(zhǔn)化組織ITU-T、中國通信標(biāo)準(zhǔn)化協(xié)會（CCSA）正式立項(xiàng)。因此《研發(fā)運(yùn)營能力一體化能力成熟度模型》已經(jīng)成為全球首個(gè)DevOps標(biāo)準(zhǔn)。

《研發(fā)運(yùn)營一體化能力成熟度模型》共分為八個(gè)部分，分別是總體架構(gòu)、敏捷開發(fā)管理、持續(xù)交付、技術(shù)運(yùn)營、應(yīng)用設(shè)計(jì)、安全及風(fēng)險(xiǎn)管理、評估方法、系統(tǒng)和工具。其中《研發(fā)運(yùn)營一體化（DevOps）能力成熟度模型第3部分：持續(xù)交付》基本上定義了DevOps的關(guān)鍵技術(shù)。該模型定義了配置管理、構(gòu)建與持續(xù)集成、測試管理、部署與發(fā)布管理、環(huán)境管理、數(shù)據(jù)管理、度量與反饋七大能力域，涵蓋版本控制、變更管理、構(gòu)建實(shí)踐、持續(xù)集成、測試分層策略、代碼質(zhì)量管理、自動化測試等49個(gè)子項(xiàng)，每個(gè)子項(xiàng)分為五個(gè)級別，不同級別的能力要求不同，綜合考量整個(gè)持續(xù)交付過程管理，最終得出評估級別。

7個(gè)能力域基本定義了DevOps不同維度的關(guān)鍵技術(shù)，比如配置管理里面四個(gè)關(guān)鍵技術(shù)分別是：版本變更標(biāo)準(zhǔn)化，將一切納入版本控制，全流程可追溯和單一可信數(shù)據(jù)源。持續(xù)集成會要求每次提交觸發(fā)完整的流水線每次提交觸發(fā)完整的流水線，每次流水線觸發(fā)自動化測試，出了問題可以在第一時(shí)間修復(fù)等關(guān)鍵技術(shù)。測試管理會定義自動化測試的分層測試及其自動化測試的代碼覆蓋率、BUG率等質(zhì)量指標(biāo)。度量與反饋分別代表了軟件交付的兩個(gè)最重要的方面，也就是交付效率和交付質(zhì)量，其中DevOps的主要4個(gè)度量指標(biāo)包括：

1）部署頻率：指應(yīng)用和服務(wù)向生產(chǎn)環(huán)境部署代碼的頻率;

2）變更前置時(shí)間：指代碼從提交到成功運(yùn)行在生產(chǎn)環(huán)境的時(shí)長;

3）服務(wù)恢復(fù)時(shí)間：指線上應(yīng)用和服務(wù)出現(xiàn)故障到恢復(fù)運(yùn)行的時(shí)長;

4）變更失敗率：指應(yīng)用和服務(wù)在生產(chǎn)環(huán)境部署失敗或者部署后導(dǎo)致服務(wù)降級的比例。

4 傳統(tǒng)銀行DevOps轉(zhuǎn)型關(guān)鍵步驟

傳統(tǒng)銀行要實(shí)現(xiàn)DevOps轉(zhuǎn)型，可以從團(tuán)隊(duì)及組織架構(gòu)、文化、流程、工具.平臺等多個(gè)維度進(jìn)行DevOps轉(zhuǎn)型實(shí)踐。

1）按照DevOps實(shí)踐要求，構(gòu)建一個(gè)跨業(yè)務(wù)、開發(fā)、測試、運(yùn)維、安全等多領(lǐng)域的敏捷高效的全棧團(tuán)隊(duì)、特性團(tuán)隊(duì)等。由于傳統(tǒng)銀行存在業(yè)務(wù)部門、IT開發(fā)、IT測試、IT運(yùn)維的部門壁壘，需要推動組織文化的革新和流程優(yōu)化，來形成一個(gè)溝通協(xié)作高效的敏捷虛擬團(tuán)隊(duì)，從而實(shí)現(xiàn)追求更加敏捷高效的IT交付。那么如何調(diào)整團(tuán)隊(duì)組織結(jié)構(gòu)，建立一個(gè)Scrum敏捷團(tuán)隊(duì)呢？一般會按照業(yè)務(wù)功能劃分團(tuán)隊(duì)，建立溝通群組，設(shè)置產(chǎn)品負(fù)責(zé)人（多個(gè)業(yè)務(wù)人員）、Scrum Master（我們一般選擇測試人員擔(dān)任，測試驅(qū)動開發(fā)模式）和開發(fā)者團(tuán)隊(duì)（前端工程師、后端工程師、測試、運(yùn)維各若干名）。

2）DevOps轉(zhuǎn)型過程中，在傳統(tǒng)銀行內(nèi)宣貫和學(xué)習(xí)DevOps文化也是十分重要的環(huán)節(jié)。著名的管理學(xué)大師彼得·德魯克，曾經(jīng)說過，文化對于一個(gè)組織的是非常的重要，對于企業(yè)和組織來說，沒有文化的組織將無法持續(xù)前行。在不同的文化制度中，相同的人發(fā)揮出來的生產(chǎn)力也會有天壤之別，在敏捷團(tuán)隊(duì)主動去實(shí)踐DevOps文化更是關(guān)系到DevOps能否轉(zhuǎn)型成功的關(guān)鍵環(huán)節(jié)。DevOps的核心文化是CALMS，具體含義：

①Culture（文化）一是指擁抱變革，促進(jìn)協(xié)作和溝通;

②Automation（自動化）一是指將人為干預(yù)的環(huán)節(jié)從價(jià)值鏈中消除;

③Lean（精益）一是指通過使用精益原則促使高頻率循環(huán)周期;

④Metrics（指標(biāo)）一是指衡量每一個(gè)環(huán)節(jié)，并通過數(shù)據(jù)來改進(jìn)循環(huán)周期;

⑤Sharing（分享）一是指與他人開放分享成功與失敗的經(jīng)驗(yàn)，并在錯(cuò)誤中不斷學(xué)習(xí)改進(jìn)。

其中溝通、協(xié)作、集成、自動化是DevOps具體落地實(shí)踐的應(yīng)用方法，并且Garnter提出的多態(tài)IT管理模型中提到創(chuàng)新是IT的驅(qū)動力和引領(lǐng)業(yè)務(wù)的源泉。只有IT的創(chuàng)新，才能在21世紀(jì)的商業(yè)模式上，不斷地提升業(yè)務(wù)的交付價(jià)值與業(yè)務(wù)成果。

3）在流程方面，項(xiàng)目組需要建設(shè)一套完備的持續(xù)可交付的流程。該流程包含業(yè)務(wù)需求、編碼構(gòu)建、測試環(huán)境、生產(chǎn)部署四個(gè)環(huán)節(jié)，各個(gè)環(huán)節(jié)相互銜接，服務(wù)相互聯(lián)動，所測即所投。從開發(fā)人員接到需求后，根據(jù)相關(guān)需求拆分成史詩、特性、用戶故事等，然后敏捷團(tuán)隊(duì)根據(jù)特性、用戶故事等進(jìn)行迭代開發(fā)（迭代周期一般為2-4周），開發(fā)人員將開發(fā)的代碼提交后，會自動進(jìn)行編譯、打包、構(gòu)建、代碼掃描、質(zhì)量門禁等，然后自動生成制品庫，并觸發(fā)功能測試、集成測試等環(huán)節(jié)，在測試通過后在通過自動化部署流程完成版本的自動化生產(chǎn)部署，完成版本的發(fā)布。自動化測試流程一般包括測試人員提前介入到需求分析階段，根據(jù)需求制定測試計(jì)劃，并編寫測試用例，利用自動化測試工具完成測試工作，并將測試報(bào)告發(fā)給開發(fā)人員。運(yùn)營監(jiān)控流程一般包括優(yōu)化監(jiān)控體系、完善運(yùn)營反饋。比如基礎(chǔ)環(huán)境、應(yīng)用、數(shù)據(jù)庫等的監(jiān)控、日志采集、日志監(jiān)控、全鏈路監(jiān)控、質(zhì)量監(jiān)控等，并形成對監(jiān)控告警信息的及時(shí)處理等。通過這一系列流程可以比較友好地推進(jìn)自動化測試的流程、完善運(yùn)營監(jiān)控的流程，達(dá)到良好的效果。

4）在流程構(gòu)建優(yōu)化方面，我們要從三個(gè)方面考慮，一要整體全面思考，出現(xiàn)問題時(shí)要從整個(gè)系統(tǒng)出發(fā)，優(yōu)化整個(gè)環(huán)節(jié)中可能存在問題的各個(gè)部分，達(dá)到標(biāo)本兼治徹底解決問題。二要發(fā)揮項(xiàng)目成員的創(chuàng)造性和主觀能動性，這點(diǎn)很重要。所有的事情都是要靠優(yōu)秀的項(xiàng)目成員來完成的。三是數(shù)據(jù)驅(qū)動，通過數(shù)據(jù)去發(fā)現(xiàn)改進(jìn)的點(diǎn)，然后度量改進(jìn)的效果，然后持續(xù)改進(jìn)，達(dá)到完美效果。

5）在工具及平臺方面，傳統(tǒng)銀行DevOps轉(zhuǎn)型可以選擇成熟的DevOps產(chǎn)品工具，若是有條件的話也可以自建DevOps研發(fā)平臺。當(dāng)前根據(jù)DevOps的階段分類，大致可以將工具分為如下類別：

①代碼管理（SCM）：GitHub、GitLab、BitBucket、SubVersion

②構(gòu)建工具：Ant、Cradle、maven

③自動部署：Capistrano .CodeDeploy

④持續(xù)集成（ CI）：Bamboo .Hudson .Jenkins

⑤配置管理：Ansible、Chef. Puppet、SaltStack. ScriptRockGuardRail容器：Docker.LXC .Kubernetes .Apache Mesos

⑥服務(wù)注冊與發(fā)現(xiàn)：Zookeeper.etcd.Consul腳本語言：py-thon .ruby .sheU

⑦日志管理：ELK .Logentries

⑧系統(tǒng)監(jiān)控：Datadog、Graphite .Icinga .Nagios

⑨性能監(jiān)控：AppDynamics .New Relic .Splunk

⑩壓力測試：JMeter.Blaze Meter.loader.io

（11）項(xiàng)目管理（ PM）：Jira.Asana.Taiga .Trello .Basecamp .Piv-otal Tracker .AzureDevOps

另外，對于有條件的銀行也可以以現(xiàn)有工具為中心，集合各環(huán)節(jié)流程工具，統(tǒng)一數(shù)據(jù)視圖、形成研發(fā)閉環(huán)、自動化全流程，建設(shè)一套滿足持續(xù)集成、持續(xù)交付、運(yùn)營反饋的一體化平臺。

5 結(jié)語

隨著各大銀行數(shù)字化轉(zhuǎn)型的深入，DevOps轉(zhuǎn)型已成為銀行數(shù)字化轉(zhuǎn)型的必選之路，驅(qū)動敏捷DevOps轉(zhuǎn)型的第一步往往是重塑IT組織協(xié)作方式，提升價(jià)值交付效率。轉(zhuǎn)型的核心絕非僅限于效率，而是在于提升業(yè)務(wù)響應(yīng)力，因此要求銀行實(shí)現(xiàn)“端到端”的數(shù)字化，比如改善多渠道客戶體驗(yàn)、豐富客戶分析以及全面簡化客戶流程以實(shí)現(xiàn)業(yè)務(wù)敏捷性，對接IT技術(shù)敏捷性，研發(fā)運(yùn)營一體化。

參考文獻(xiàn)：

[1] https：//mp. weixin. qq. com/s/Uz5AIMJXinZmR-eyY4W88Q重磅！《2020年中國DevOps現(xiàn)狀調(diào)查》全面啟動！

[2] https：//www.cbalicai.com/yejiedongtai/4869.html 17家大型銀行公認(rèn)的敏捷與DevOps快速轉(zhuǎn)型模型，

[3] http：//www. caict. ac. cn/xwdt/hyxw/201807/t20180703_176414.htm DevOps能力成熟度三級評估結(jié)果公布，

[4] https：//blog.csdn.net/cynthia_chf/article/details/71616448-平安7年精益敏捷轉(zhuǎn)型之路.

[5]https：//baijiahao. baidu. com/s？ id=16308445 61369016705&wfr=spider&for=pc DevOps工具分類總結(jié).

[6] https：//www.sohu.com/a/238954564_753085 DevOps能力成熟度三級評估結(jié)果公布.

[7] https：//time.geekbang.org/column/intro/235 DevOps實(shí)戰(zhàn)筆記.

【通聯(lián)編輯：梁書】

作者簡介：劉中華（1974-），男，河南鄭州人，學(xué)士，研究方向：數(shù)據(jù)挖掘、人工智能、DevOps等;孫科（1983-），男，四川成都人，高級職稱，碩士，研究方向：分布式數(shù)據(jù)庫、微服務(wù)、DevOps等。