中國銀河證券股份有限公司，作為中國證券行業(yè)領(lǐng)先的綜合金融服務提供商，致力于成為在亞洲資本市場上領(lǐng)先的投資銀行和具有系統(tǒng)重要性的證券業(yè)金融機構(gòu)。中國銀河證券目前已在國內(nèi)擁有證券市場業(yè)務全牌照以及覆蓋較廣的營業(yè)網(wǎng)絡，業(yè)務遍及全球15個國家和地區(qū)，覆蓋國內(nèi)31個省/自治區(qū)/直轄市、178個地級以上城市，有著近500家營業(yè)部。

而中國銀河證券的DevOps建設(shè)經(jīng)歷了由下而上和由上至下兩個發(fā)展階段，也是國內(nèi)金融企業(yè)在建設(shè)DevOps過程中比較典型的發(fā)展路徑，因而中國銀河證券DevOps建設(shè)的破冰之路，是證券行業(yè)DevOps建設(shè)案例中的典型。

今天，很榮幸以DevOps負責人的第一視角，帶領(lǐng)大家走進中國銀河證券DevOps建設(shè)的破冰之路。接下來將按照中國銀河證券DevOps建設(shè)的時間軸，分為“破冰前夕”、“如何破冰”、“建設(shè)現(xiàn)狀”以及“下一步規(guī)劃”四部分來逐一詳細介紹，希望能給證券同行構(gòu)建企業(yè)級DevOps體系帶來一些思路與啟發(fā)。

*注：以下內(nèi)容整理自：中國銀河證券DevOps項目負責人 黃金澤 于 嘉為藍鯨2022研運一體創(chuàng)新峰會的精彩分享——《中國銀河證券DevOps建設(shè)的破冰之路》

01. 破冰前夕

在企業(yè)級DevOps平臺建設(shè)的前期，中國銀河證券已有近百人規(guī)模的自主研發(fā)團隊，此時的工具集以開源與免費的工具為主。研發(fā)人員自發(fā)組織建設(shè)DevOps的工具，呈現(xiàn)點狀分布、工具功能單一、服務連續(xù)性弱的特點，也很少會做業(yè)務連續(xù)性和工具鏈集群部署，同時有重復建設(shè)的特點，這是大部分國內(nèi)金融企業(yè)DevOps的現(xiàn)狀。

這個階段建設(shè)DevOps的初衷，是為了提高工作效率，解決當下問題。這時候的DevOps工具的建設(shè)，通常由研發(fā)人員自發(fā)地建設(shè)解決自己的問題為主，并不由上層領(lǐng)導推動，提供的服務也以研發(fā)人員解決自己痛點為出發(fā)點。

比如像中國銀河證券，早期使用了JIRA、Confluence、Gitlab、SVN、Jenkins、SonarQube、Nexus和Ansible等常見的開源工具。其實當這些工具上來的時候，大家還是眼前一亮的，因為效率工具切實地解放了個體研發(fā)人員的雙手。這也是很多組織在建設(shè)“企業(yè)級”DevOps工具體系前的狀態(tài)。

但可以看到，這個階段還只是在局部解決一些效率問題，因為在DevOps整體工具建設(shè)上的痛點，單靠研發(fā)人員本身力量是難以推動解決的。

DevOps整體工具建設(shè)的痛點是指什么呢？

具體來說，就是工具的功能過于單一，都是解決個體研發(fā)人員的問題，別人想用還要單獨搭一套。而企業(yè)內(nèi)每個人都搭一套工具的話，就是浪費資源的重復建設(shè)，同時工具之間也豎起了各種數(shù)據(jù)流轉(zhuǎn)的隔離墻，企業(yè)IT的整體效率反而被消耗掉了。

所以DevOps工具建設(shè)的下一個階段，需要企業(yè)花費大量精力做工具間的集成，通過整合工具、打通權(quán)限、打通測試數(shù)據(jù)和日志等數(shù)據(jù)流，使代碼能夠在工具之間流轉(zhuǎn)。

此時，企業(yè)建設(shè)下一階段的DevOps體系，面臨著兩個大方向的選擇：

• 一就是增加大量的人手，通過集成工具來搭建企業(yè)級DevOps平臺。
• 二就是花錢購買成熟的商業(yè)產(chǎn)品，來實現(xiàn)同樣的目標。

說白了，就是看企業(yè)更缺人，還是更缺錢。

當然還有另一個更高級的選擇，就是既不缺人也不缺錢的企業(yè)，那可以考慮自研DevOps平臺，自研的東西適配度肯定是最好的。

那回到大多數(shù)企業(yè)建設(shè)DevOps工具體系的方向性選擇上，我們可以綜合來看兩者的利弊。

就集成工具方案而言，弊端有三點：

• 一是人不好找。通過集成工具打造DevOps體系化工具，需要去招聘市場上招聘人才，而擁有成熟經(jīng)驗的DevOps工程師市場上本就不太多。大多數(shù)時候，企業(yè)需要自己慢慢地培養(yǎng)。
• 二是建設(shè)周期比較長。工具之間數(shù)據(jù)標準并不統(tǒng)一，打通權(quán)限和任務流轉(zhuǎn)需要做大量的二次開發(fā)，開發(fā)后需要調(diào)試和反復的調(diào)優(yōu)。沒有多年的建設(shè)，很難說交付一個好用的DevOps平臺。
• 三是后期的研發(fā)度量其實非常難做。研發(fā)度量是在DevOps平臺建設(shè)成熟、穩(wěn)定使用后更高一層級的需求，可以理解為是研發(fā)工具的中臺系統(tǒng)，它能提供研發(fā)過程的各類數(shù)據(jù)。在建設(shè)到這個階段的時候，企業(yè)就會發(fā)現(xiàn)，前期工具整合的深度還遠遠不夠，還需要進一步地整合。而二次開發(fā)越多，工具本身的升級就越困難，這就掉入了一個坑里。

那集成工具的優(yōu)勢是什么呢？

優(yōu)勢是企業(yè)經(jīng)過大量的二次開發(fā)，通過與項目團隊多年的磨合，不停地迭代、改造，磨合出了企業(yè)自己的一套DevOps平臺，它花費了企業(yè)本身很大的精力，那它的優(yōu)勢就是較大程度上適合這家企業(yè)的。

但是企業(yè)需要經(jīng)歷前面一到兩年，甚至兩到三年的痛苦期。集成工具的前幾年，它可能不會帶來效率的提升，甚至可能拖累整個研發(fā)效率，DevOps團隊是會被質(zhì)疑的，甚至團隊活不到平臺建成那一天。

那砸錢買的成熟平臺，優(yōu)勢又是什么呢？

• 優(yōu)勢就是快。可以馬上吸取行業(yè)多年的沉淀經(jīng)驗，工具里面固化的經(jīng)驗和方法，企業(yè)拿來就能用。
• 再一個就是不容易走彎路。DevOps平臺的建設(shè)非常依賴DevOps負責人的經(jīng)驗，他的方向錯了，平臺很可能就失敗了。

可成熟平臺的劣勢是什么呢？

劣勢就是產(chǎn)品只能適配企業(yè)七八成的需求。

比如企業(yè)里面有一個特殊的系統(tǒng)，有特殊的構(gòu)建和部署方式，那產(chǎn)品只能優(yōu)先考慮解決七八成通用構(gòu)建方式的系統(tǒng)，最后才會考慮適配這些特殊的系統(tǒng)。而且在適配上，也有需要企業(yè)項目組自己去適應產(chǎn)品的地方，而不是由產(chǎn)品來適應所有的項目組。產(chǎn)品沒有辦法保證，能夠百分百適應所有團隊的使用習慣。

以上就是企業(yè)級DevOps工具體系建設(shè)的兩種路線選擇，可以根據(jù)自身企業(yè)的情況來做出選擇，并沒有一個行業(yè)通行的做法。

02. 如何破冰

首先，需要自上而下推動企業(yè)DevOps平臺的建設(shè)。可能有人會問，怎么自上而下呢？

因為DevOps的工具特點就是解決研發(fā)測試人員本身的問題，而不是解決上層領(lǐng)導的問題。上層領(lǐng)導可能看不到研發(fā)怎么解決的問題、問題解決得怎么樣，看不到的問題，那就覺得沒有問題。

所以，這就需要有個抓手，能夠提起上面領(lǐng)導的重視，同步解決研發(fā)人員自己的問題。

這個抓手，就是研發(fā)度量。

前面提到，研發(fā)度量就是企業(yè)研發(fā)工具建設(shè)的中臺系統(tǒng)。通過讓研發(fā)人員都在DevOps平臺上來干活，干活就產(chǎn)生數(shù)據(jù)，有數(shù)據(jù)就可以作分析，分析出來的內(nèi)容就可以度量，度量出哪里好、哪里不好、哪里有瓶頸，同時還能考核外部的廠商。

這就抓住了上面領(lǐng)導的需求，同時解決了下面的問題。所以說，度量就是推動自上而下的一個關(guān)鍵，也是破冰的抓手。

DevOps的建設(shè)是企業(yè)數(shù)字化轉(zhuǎn)型的前提和基礎(chǔ)，幾乎所有的自主研發(fā)型IT團隊都離不開DevOps。我們過去時常提及企業(yè)數(shù)字化，那企業(yè)里面研發(fā)人員都沒能數(shù)字化，他們都沒有效率工具和研發(fā)過程可視化工具，他們都沒有自己的中臺，又如何讓企業(yè)內(nèi)業(yè)務部門數(shù)字化呢，又如何懂給別人建中臺呢？

所以DevOps平臺是非常重要的基礎(chǔ)設(shè)施，沒有DevOps平臺的企業(yè)搞數(shù)字化，研發(fā)人員其實就是帶著腳鐐在跳舞。

中國銀河證券從2013年起就開始了建設(shè)DevOps，當時首先引進了項目管理工具JIRA和Confluence。

2013年至2019年，是自下而上建設(shè)DevOps的階段，這時候使用了大量的免費開源工具，分散式地構(gòu)建了大量的技術(shù)棧。

2019年至2021年，通過引進外部咨詢加開源工具的方式，初步整合及搭建起企業(yè)級DevOps的工具鏈。

2021年到2022年，公司通過采購成熟的商業(yè)產(chǎn)品加整合已有工具的形式，自上而下地建設(shè)了DevOps平臺，幫助我們更好地推動企業(yè)數(shù)字化轉(zhuǎn)型。

03. 破冰現(xiàn)狀

目前通過引入嘉為藍鯨產(chǎn)品，中國銀河證券逐步搭建起了適合自身業(yè)務特性的DevOps平臺。

以下是DevOps完整流水線的配置示意圖，可以看到中國銀河證券是重流水線設(shè)計型的，而有一些企業(yè)是輕流水線設(shè)計型的，這個沒有好壞之分。在中國銀河證券流水線的應用里面，會設(shè)置有大量的門禁和審批節(jié)點，幫助中國銀河證券實現(xiàn)研發(fā)管理的自動化和強管控。

以下是我們自動化測試工具接入平臺的示意圖。目前，中國銀河證券已陸續(xù)建設(shè)了接口測試、單元測試和UI自動化測試，后面還計劃建設(shè)性能測試和安全測試。

以下是DevOps流水線的質(zhì)量門禁。通過整合測試相關(guān)的數(shù)據(jù)，在流水線中加入可以定制化的質(zhì)量門禁。開發(fā)的日常工作中會有很多定制化的數(shù)據(jù)進來，當不符合門禁要求的代碼流經(jīng)流水線的時候，門禁就會自動化攔截并通知相關(guān)開發(fā)人員，實現(xiàn)代碼質(zhì)量的自動化管控。

測試作為流水線里邊很重要的一個環(huán)節(jié)，它是后面能做門禁數(shù)據(jù)的一個前提，也是門禁數(shù)據(jù)的其中一個來源。只要自動化測試做得好，我們就可以節(jié)省很多功能測試的相關(guān)人員。

以下是DevOps數(shù)據(jù)打通的示意圖，自前期設(shè)計的時候開始，中國銀河證券就已經(jīng)做好了打通所有研發(fā)數(shù)據(jù)的準備。中國銀河證券基于JIRA的需求編號，通過讓開發(fā)人員在代碼提交時，要求在Git Commit Message中關(guān)聯(lián)到JIRA需求編號的形式，將需求任務、開發(fā)任務、缺陷代碼、流水線集成、部署制品，數(shù)據(jù)打通并關(guān)聯(lián)到一起，為后續(xù)度量平臺的建設(shè)提供了數(shù)據(jù)上的支持。

以下是DevOps工具打通的示意圖。黃色的部分是引入嘉為藍鯨DevOps平臺的能力，在與原有工具（藍色）整合后，構(gòu)建起中國銀河證券的DevOps工具全景圖。

可以看到，研發(fā)度量是中國銀河證券在建設(shè)DevOps工具體系前，就提前考慮好的重要建設(shè)內(nèi)容。若不提前鋪墊，后面在建設(shè)研發(fā)度量的時候，就會遇到工具集成深度不夠、數(shù)據(jù)打通不足的問題。

04. 后續(xù)展望

以下這張圖是研發(fā)度量平臺建設(shè)的5個階段，包括最開始的敏捷理念的推廣，然后是研發(fā)過程的標準化、工具的準備和打通，再然后是指標體系的建設(shè)，最后是度量指標促進標準執(zhí)行。目前中國銀河證券剛完成研發(fā)標準化、業(yè)務自動化和工具智能化的建設(shè)，正在推進研發(fā)度量領(lǐng)域推進指標體系的建設(shè)。

下一階段就是平臺建設(shè)完畢后，中國銀河證券將通過度量平臺反哺企業(yè)研發(fā)過程，發(fā)現(xiàn)研發(fā)瓶頸、促進效率的進一步提升，這正是中國銀河證券研發(fā)度量的核心目標。

中國銀河證券也將積極響應國家信創(chuàng)計劃，推動DevOps平臺信創(chuàng)建設(shè)。同時中國銀河證券也計劃在明年通過信通院DevOps三級標準。

中國銀河證券的DevOps平臺建設(shè)將不僅僅局限于對應用發(fā)布的自動化，也會持續(xù)向配置管理和數(shù)據(jù)發(fā)布自動化發(fā)展。未來，DevOps平臺將會滲入到研發(fā)過程的方方面面，全面提升軟件研發(fā)全生命周期各環(huán)節(jié)的效率與質(zhì)量。

以上，便是中國銀河證券關(guān)于DevOps平臺建設(shè)過程，以及如何在企業(yè)里推進自上而下建設(shè)DevOps的經(jīng)驗分享，希望能給證券同行構(gòu)建DevOps工具體系帶來建設(shè)啟發(fā)與參考價值，感謝各位的聆聽。