淺談傳統(tǒng)銀行的DevOps轉(zhuǎn)型

1、    淺談傳統(tǒng)銀行的devops轉(zhuǎn)型    劉中華 孫科摘要：傳統(tǒng)銀行在強監(jiān)管背景下，如何能夠在互聯(lián)網(wǎng)金融的沖擊下順利完成數(shù)字化轉(zhuǎn)型已成為各大銀行的首要任務(wù)，針對該問題本文通過介紹devops主要概念、分析devops的關(guān)鍵技術(shù)，提出了傳統(tǒng)銀行可以從團隊及組織架構(gòu)、文化、流程、工具、平臺等多個維度進行devops轉(zhuǎn)型實踐的思考，從而為傳統(tǒng)銀行的devops轉(zhuǎn)型提供參考。關(guān)鍵詞：devops;銀行轉(zhuǎn)型;devops轉(zhuǎn)型;敏捷開發(fā);銀行數(shù)字化：tp39 ：a：1009-3044（2020）29-0236-031 前言伴隨著devops在全球各行業(yè)快速流行，

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

3、未艾，在強監(jiān)管的要求下，傳統(tǒng)銀行也面臨著較大的危機，如何破局成為各大銀行的首要任務(wù)。因此，敏捷和devops也逐漸進入以合規(guī)和穩(wěn)健為主流文化的傳統(tǒng)銀行業(yè)，目前devops轉(zhuǎn)型在銀行業(yè)已成燎原之勢，中國銀行業(yè)敏捷轉(zhuǎn)型之大幕已經(jīng)拉開，“5+12”銀行（5家國有商業(yè)銀行+12家股份制銀行）都在大力推進21。根據(jù)中國信息通信研究院研究金牌運維評估數(shù)據(jù)顯示，devops正遍地開花，在各種規(guī)模的企業(yè)中落地，截至2017年已有78%的企業(yè)使用開源的自動化運維工具3。2 devops概念每當(dāng)提及devops是什么的時候，由于不限定人群和范圍，每個人都能從自己的立場來解讀devops，很多行業(yè)先行者給出的定義也

4、常常不同，devops之父patrick第一次參加dev0-psdays中國站活動的時候，也使用“盲人摸象”比喻大家對de-vops的認(rèn)識，因為devops運動從誕生起，devops文化一直在不斷發(fā)展和進步，這些先行者們就從來沒有試圖給devops下一個官方的定義。與其糾結(jié)于devops的定義，不如讓我們一起回歸原始，來看看devops究竟要解決的是什么問題。其實，devops的秘密就來源于它的名字所代表的兩種角色開發(fā)（development）和運維（operations）。那么這兩種角色之間究竟有什么問題呢？我們從軟件工程誕生以來所歷經(jīng)的三個重要發(fā)展階段說起。第一階段：瀑布開發(fā)模式。瀑布式開

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

6、更高的成功率和生產(chǎn)率，也被稱作迭代增量式開發(fā)或迭代進化式開發(fā)。在迭代開發(fā)模式中，項目組會將整個項目劃分為一系列的短小的、固定長度（如2周）的小項目也就是一個迭代周期，每一次迭代都包括了需求分析、設(shè)計、實現(xiàn)與測試。采用這種模式，開發(fā)工作是在需求被完整地確定之前啟動，并在一次迭代中完成系統(tǒng)的一部分相對完整的功能，然后通過客戶的反饋來細(xì)化需求，并開始新一輪的迭代。敏捷迭代開發(fā)模式看似每個迭代花費了更多的時間，但是在每個迭代就讓用戶介入反饋確保其實施的正確性，節(jié)省了大量不必要的浪費和返工。第三階段：devops開發(fā)模式，敏捷迭代開發(fā)模式雖然解決了開發(fā)與測試快速協(xié)作問題，并使得開發(fā)和測試測試團隊能夠抱團

7、取暖，可是問題又來了，開發(fā)和測試團隊發(fā)現(xiàn)，不管研發(fā)的速度變得多快，在軟件交付的另一端，如果沒有經(jīng)過運維環(huán)節(jié)的部署上線，并最終發(fā)布給真實用戶，那么這些功能其實并沒有什么用。在墻的另一端的運維團隊成了被拉攏的對象。這些在軟件交付最末端的團隊始終處于一種“背鍋”的狀態(tài)，他們也有改變的意愿，所以devops應(yīng)運而生，也就是說，devops最開始想要打破的就是開發(fā)和運維之間的對立和隔閡。除此之外，運維團隊慢慢轉(zhuǎn)向運營團隊，他們持續(xù)不斷地把線上的真實數(shù)據(jù)和用戶行為及時地反饋給需求團隊，來幫助需求團隊客觀評估需求的價值，并及時作出有利于產(chǎn)品發(fā)展的調(diào)整，很快業(yè)務(wù)部門被引入到devops之中。除此之外，系統(tǒng)上線

8、后安全成為系統(tǒng)必須解決的問題，在每個過程中會注入安全反饋機制，來幫助團隊在第一時間應(yīng)對安全風(fēng)險，那么，安全團隊也有加入devops的需求。這樣的例子比比皆是，包括職能部門、戰(zhàn)略部門等，都紛紛加入其中，使得devops由最開始的點，擴展為線，再到面，不斷發(fā)展壯大。每個人都參與其中，這使得de-vops成了每一個it從業(yè)人員都需要學(xué)習(xí)和了解的知識和技能體系。devops代表了it文化的變化，在面向系統(tǒng)全局（上下文）采用敏捷、精益實踐，關(guān)注于快速的it服務(wù)交付。因此，devops可以定義為（開發(fā)development與運維oper-ations的組合詞）是一種文化、一場運動或?qū)嵺`，強調(diào)在自動化軟件交

9、付流程及基礎(chǔ)設(shè)施變更過程中，軟件開發(fā)人員與其他信息技術(shù)（測試、運維、業(yè)務(wù)、安全、職能部門等）專業(yè)人員彼此之間的協(xié)作與溝通。它旨在建立一種文化與環(huán)境，使構(gòu)建、測試、軟件發(fā)布得以快速、頻繁以及更加穩(wěn)定地進行。3 devops的關(guān)鍵技術(shù)在2017年底，由中國信息通信研究院云計算開源產(chǎn)業(yè)聯(lián)盟（oscar）聯(lián)合高效運維社區(qū)、devops時代、騰訊、京東、浙江移動、中國銀行、中國電信、太平洋保險集團等行業(yè)頂級技術(shù)專家100多名，共同編寫制定了國內(nèi)外第一個devops系列標(biāo)準(zhǔn)研發(fā)運營能力一體化能力成熟度模型，該系列標(biāo)準(zhǔn)分為敏捷開發(fā)管理、持續(xù)交付、技術(shù)運營、應(yīng)用設(shè)計、安全風(fēng)險管理和組織結(jié)構(gòu)7個部分，涵蓋了全軟

10、件的開發(fā)和運維生命周期，這是行業(yè)智慧的結(jié)晶，也為構(gòu)建云時代下的新型軟件開發(fā)與運營模式奠定堅實的基礎(chǔ)3。在2018年9月份，該devops標(biāo)準(zhǔn)已在聯(lián)合國直屬標(biāo)準(zhǔn)化組織itu-t、中國通信標(biāo)準(zhǔn)化協(xié)會（ccsa）正式立項。因此研發(fā)運營能力一體化能力成熟度模型已經(jīng)成為全球首個devops標(biāo)準(zhǔn)。研發(fā)運營一體化能力成熟度模型共分為八個部分，分別是總體架構(gòu)、敏捷開發(fā)管理、持續(xù)交付、技術(shù)運營、應(yīng)用設(shè)計、安全及風(fēng)險管理、評估方法、系統(tǒng)和工具。其中研發(fā)運營一體化（devops）能力成熟度模型第3部分：持續(xù)交付基本上定義了devops的關(guān)鍵技術(shù)。該模型定義了配置管理、構(gòu)建與持續(xù)集成、測試管理、部署與發(fā)布管理、環(huán)境管

11、理、數(shù)據(jù)管理、度量與反饋七大能力域，涵蓋版本控制、變更管理、構(gòu)建實踐、持續(xù)集成、測試分層策略、代碼質(zhì)量管理、自動化測試等49個子項，每個子項分為五個級別，不同級別的能力要求不同，綜合考量整個持續(xù)交付過程管理，最終得出評估級別。7個能力域基本定義了devops不同維度的關(guān)鍵技術(shù)，比如配置管理里面四個關(guān)鍵技術(shù)分別是：版本變更標(biāo)準(zhǔn)化，將一切納入版本控制，全流程可追溯和單一可信數(shù)據(jù)源。持續(xù)集成會要求每次提交觸發(fā)完整的流水線每次提交觸發(fā)完整的流水線，每次流水線觸發(fā)自動化測試，出了問題可以在第一時間修復(fù)等關(guān)鍵技術(shù)。測試管理會定義自動化測試的分層測試及其自動化測試的代碼覆蓋率、bug率等質(zhì)量指標(biāo)。度量與反饋

12、分別代表了軟件交付的兩個最重要的方面，也就是交付效率和交付質(zhì)量，其中devops的主要4個度量指標(biāo)包括：1）部署頻率：指應(yīng)用和服務(wù)向生產(chǎn)環(huán)境部署代碼的頻率;2）變更前置時間：指代碼從提交到成功運行在生產(chǎn)環(huán)境的時長;3）服務(wù)恢復(fù)時間：指線上應(yīng)用和服務(wù)出現(xiàn)故障到恢復(fù)運行的時長;4）變更失敗率：指應(yīng)用和服務(wù)在生產(chǎn)環(huán)境部署失敗或者部署后導(dǎo)致服務(wù)降級的比例。4 傳統(tǒng)銀行devops轉(zhuǎn)型關(guān)鍵步驟傳統(tǒng)銀行要實現(xiàn)devops轉(zhuǎn)型，可以從團隊及組織架構(gòu)、文化、流程、工具.平臺等多個維度進行devops轉(zhuǎn)型實踐。1）按照devops實踐要求，構(gòu)建一個跨業(yè)務(wù)、開發(fā)、測試、運維、安全等多領(lǐng)域的敏捷高效的全棧團隊、特性

13、團隊等。由于傳統(tǒng)銀行存在業(yè)務(wù)部門、it開發(fā)、it測試、it運維的部門壁壘，需要推動組織文化的革新和流程優(yōu)化，來形成一個溝通協(xié)作高效的敏捷虛擬團隊，從而實現(xiàn)追求更加敏捷高效的it交付。那么如何調(diào)整團隊組織結(jié)構(gòu)，建立一個scrum敏捷團隊呢？一般會按照業(yè)務(wù)功能劃分團隊，建立溝通群組，設(shè)置產(chǎn)品負(fù)責(zé)人（多個業(yè)務(wù)人員）、scrum master（我們一般選擇測試人員擔(dān)任，測試驅(qū)動開發(fā)模式）和開發(fā)者團隊（前端工程師、后端工程師、測試、運維各若干名）。2）devops轉(zhuǎn)型過程中，在傳統(tǒng)銀行內(nèi)宣貫和學(xué)習(xí)devops文化也是十分重要的環(huán)節(jié)。著名的管理學(xué)大師彼得·德魯克，曾經(jīng)說過，文化對于一個組織的是非

14、常的重要，對于企業(yè)和組織來說，沒有文化的組織將無法持續(xù)前行。在不同的文化制度中，相同的人發(fā)揮出來的生產(chǎn)力也會有天壤之別，在敏捷團隊主動去實踐devops文化更是關(guān)系到devops能否轉(zhuǎn)型成功的關(guān)鍵環(huán)節(jié)。devops的核心文化是calms，具體含義：culture（文化）一是指擁抱變革，促進協(xié)作和溝通;automation（自動化）一是指將人為干預(yù)的環(huán)節(jié)從價值鏈中消除;lean（精益）一是指通過使用精益原則促使高頻率循環(huán)周期;metrics（指標(biāo)）一是指衡量每一個環(huán)節(jié)，并通過數(shù)據(jù)來改進循環(huán)周期;sharing（分享）一是指與他人開放分享成功與失敗的經(jīng)驗，并在錯誤中不斷學(xué)習(xí)改進。其中溝通、協(xié)作、集

15、成、自動化是devops具體落地實踐的應(yīng)用方法，并且garnter提出的多態(tài)it管理模型中提到創(chuàng)新是it的驅(qū)動力和引領(lǐng)業(yè)務(wù)的源泉。只有it的創(chuàng)新，才能在21世紀(jì)的商業(yè)模式上，不斷地提升業(yè)務(wù)的交付價值與業(yè)務(wù)成果。3）在流程方面，項目組需要建設(shè)一套完備的持續(xù)可交付的流程。該流程包含業(yè)務(wù)需求、編碼構(gòu)建、測試環(huán)境、生產(chǎn)部署四個環(huán)節(jié)，各個環(huán)節(jié)相互銜接，服務(wù)相互聯(lián)動，所測即所投。從開發(fā)人員接到需求后，根據(jù)相關(guān)需求拆分成史詩、特性、用戶故事等，然后敏捷團隊根據(jù)特性、用戶故事等進行迭代開發(fā)（迭代周期一般為2-4周），開發(fā)人員將開發(fā)的代碼提交后，會自動進行編譯、打包、構(gòu)建、代碼掃描、質(zhì)量門禁等，然后自動生成制品

16、庫，并觸發(fā)功能測試、集成測試等環(huán)節(jié)，在測試通過后在通過自動化部署流程完成版本的自動化生產(chǎn)部署，完成版本的發(fā)布。自動化測試流程一般包括測試人員提前介入到需求分析階段，根據(jù)需求制定測試計劃，并編寫測試用例，利用自動化測試工具完成測試工作，并將測試報告發(fā)給開發(fā)人員。運營監(jiān)控流程一般包括優(yōu)化監(jiān)控體系、完善運營反饋。比如基礎(chǔ)環(huán)境、應(yīng)用、數(shù)據(jù)庫等的監(jiān)控、日志采集、日志監(jiān)控、全鏈路監(jiān)控、質(zhì)量監(jiān)控等，并形成對監(jiān)控告警信息的及時處理等。通過這一系列流程可以比較友好地推進自動化測試的流程、完善運營監(jiān)控的流程，達(dá)到良好的效果。4）在流程構(gòu)建優(yōu)化方面，我們要從三個方面考慮，一要整體全面思考，出現(xiàn)問題時要從整個系統(tǒng)出發(fā)

17、，優(yōu)化整個環(huán)節(jié)中可能存在問題的各個部分，達(dá)到標(biāo)本兼治徹底解決問題。二要發(fā)揮項目成員的創(chuàng)造性和主觀能動性，這點很重要。所有的事情都是要靠優(yōu)秀的項目成員來完成的。三是數(shù)據(jù)驅(qū)動，通過數(shù)據(jù)去發(fā)現(xiàn)改進的點，然后度量改進的效果，然后持續(xù)改進，達(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 .co

18、dedeploy持續(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）項目管理（ pm）：jira.asana.taiga .trello .basecamp .piv-otal tracker .azuredevops另外，對于有條件的銀行也可以以現(xiàn)有工具為中心，集合各環(huán)節(jié)流程工具，統(tǒng)一數(shù)據(jù)視圖、形成研發(fā)閉環(huán)、自動化全流程，建設(shè)一套滿足