近日，第四屆中國金融科技產業峰會、第三屆中新（蘇州）金融科技應用博覽會在蘇州國際博覽中心開幕。大會同期舉辦的博雲“雲原生應用與實踐”分論壇彙集金融行業頭部機構與雲原生技術領域專家，共同深刻探討市場發展格局。

東吳證券資訊科技總部副總經理張之浩進行了“東吳證券 DevOps 規劃與實踐分享”主題演講，以下是演講實錄。

演講實錄

尊敬的各位嘉賓、專家，大家下午好！今天為大家介紹一下東吳證券在 DevOps 體系當中的探索和實踐，我是東吳證券資訊科技總部的張之浩，負責整個研發條線的管理。

我進入東吳證券做研發有10多年的時間，見證了東吳證券從0到1建設的整個研發體系。在這個過程當中，我們走過很多彎路，也發現了很多問題，感謝博雲的邀請，今天借這個平臺，讓我分享一些相關經驗。

01 建設背景

今天的分享包括四個部分，第一部分是整個建設背景。近年來整個金融企業，尤其是券商銀行，提的較多的概念就是數字化轉型，數字化轉型面臨了很大挑戰，一方面對於新興技術，尤其是創新技術，包括網際網路、大資料、雲端計算，人工智慧甚至區塊鏈，本身發展就特別快，對研發要求比較高，隨著研發技術逐步深入，業務發展對技術部門提出了更高要求，一方面是客戶的需求一直在變化，另一部分是希望技術直接推動業務。原來我們一直在講，業務引領技術賦能，現在更多講的是怎麼推動整個業務發展，所以從這張圖可以看到，我們當時去摘錄金融機構做數字化轉型相關文章的關鍵字，出現最大的是組織效能，怎麼做變革、怎麼做創新，對 IT 人員來說是比較高的挑戰。

東吳證券從2015年真正開始做獨立的自主研發，2015年之前，大多數的研發都依賴於供應商，做簡單的二次開發，或是簡單的工具研發，並不成體系。2015年研發規模只有20人，專案只有5個。經過幾年發展，2021年我們研發隊伍已經成量級的上升，現在大概有200多名研發、50多個專案。一個量級的發展，對於研發管理的挑戰也很大，比如在這個過程當中怎麼管需求、怎麼跨團隊協作、怎麼管理環境，在統一櫃臺集中交易的使用過程當中，不同的外圍系統都會用這個資源，有可能 A 團隊做的東西會被 B 團隊改掉，那怎麼按照規範的方式推動整個研發的流程？有一些東西是手工做的，效率非常低，原來還沒有 DevOps 體系，整個工具、所有的研發各自搭一套製品庫，帶來了很多技術問題。

2015年之後，我們逐步接觸 DevOps 體系，也是近幾年各個金融機構接觸比較多的理論體系。當時我們的做法跟很多家都不一樣，我們不是想用 DevOps 直接建一套平臺，而是首先要熟悉這套理論，然後做工具的引入。我們的做法是先拿工具引入到各個專案團隊，讓大家瞭解整個 DevOps 的自動化工具、流程化工具，提升所有研發人員的文化和意識，讓他們知道，我們的研發是可以按照一個標準化流程去做的。也是近兩年來，我們才開始真正去做整個DevOps大的平臺搭建與建設，包括後續會建一些 DevOps 體系標準，以及相關成熟度評估。

02 探索歷程

我們 DevOps 的探索歷程，是從2017年開始的。剛開始沒有研發流程，沒有統一的研發工具。那時候研發工具五花八門，各個團隊背景也不一樣，有一些團隊是從製造業、或是傳統行業去做C++，有一些是從網際網路公司挖來做的比較好的敏捷團隊，有的是應屆畢業生，只有理論一套。

一開始我們沒有整個大的統一工具，2018年開始我們做了一個事情，整個東吳證券研發中心有兩個部分，一個是蘇州研發中心，還有一部分是上海研發中心，我們把兩個研發中心的基礎管理類工具全部做了統一，包括專案管理工具、程式碼庫均做了統一，2019年專門成立了質量保障團隊，跟傳統的團隊不太一樣，除了承擔原有測試團隊的功能之外，對整個研發質量和流程做管控，部分專案使用流水線。從2020年的時候，全面推廣 Scrum，雙態流程越來越高，我們希望是在同一個體系支撐之下做的，我們全面開放 Scrum 流程，並且能夠引入自動化工具，實現程式碼審查，實現一些介面自動化測試。

在今年開始，我們正式跟博雲合作，就是完成整個 DevOps 大平臺的搭建，進行度量持續的改造過程。我們做的第一步，就是統一工具，我們用很多成熟統一的工具，讓所有研發人員瞭解 DevOps 是這麼做的，我們之前用 JIRA、Bitbucket、Confluence，這是一個全家桶，我們一直認為在工具的使用當中，並不一定哪個是最合適的，你只要用起來，在這個過程當中都是比較合適的。

我們引入了整個 Scrum 模型，包括我在內，很多同事都去考了 Scrum master ，因為我畢業的時候就加入了東吳證券，對於敏捷開發，包括對於 Scrum 模型瞭解不夠深入，經過幾年工作之後，也使用了一些工具，知道了 Scrum 模型在整個研發過程的角色、事件、會議、原則。工作一段時間、運營一段時間之後，才真正瞭解到 Scrum 可以做什麼。現在是按照 2-4 周做衝刺迭代，使整個研發團隊的效率變得更快，收集需求的速度更快，釋出版本也更快，不管業務條線還是客戶條線，給予我們的反饋都是比較正能量的。我們原來穩態的開發，按照 CMI 的邏輯去做，做一些文件，做前期的需求分析，做詳細設計、概要設計，最後做測試、驗收，週期好幾個月。業務部門說你們到底做什麼，兩到三個月都沒有成效？現在不一樣了，業務部門 2-4 周，就會出一個版本、做上線，另外一點比較好，當我釋出了新版本之後，如果出現任何問題，我們可以立刻做回退，這個是第二件事情。

第三件事情是引入流水線。我們希望每一件做的事情，都是按照既定的目標去做，我們還可以引入整個自動化環境部署、自動化測試，所有東西不應該是通過“人肉”的方式去做，引入流水線對於傳統的研發人員挑戰比較高，對於研發的介面測試、單元測試，都有比較高的要求，研發人員寫完程式碼，可以直接上傳到內部的 Git 程式碼倉庫，我們通過觸發器定時，或是根據事件的觸發，對它進行程式碼抓取、構建，以及最後的釋出，也是通過容器技術，可以快速部署整個開發環境、測試環境，甚至是生產環境，這邊程式碼剛提交，那邊就打包、編譯、上傳，甚至釋出，Bug 越早發現，修改的成本就越小，如果在生產時已經部署了，再讓客戶發現對它進行追蹤，其實效率就非常低了。

自動化測試分很多種，一方面是做介面測試，一方面做 UI 測試，在這裡面，對於研發團隊來說往往需要把整個單元測試的覆蓋度達到至少 60%-70 %的水平，做的好可以達到80%，研發人員研發程式碼之後，自然而然做單元測試，就能覆蓋到80%以上的分支，對於整個研發質量有比較高的提升。

03 DevOps平臺建設

我們前面講了引入流程，又做了自動化測試工具，最後回到從底層往上走，怎麼規範研發的流程。我講了要做流水線，這個版本怎麼做控制；做了單元測試，測試的規範是怎麼樣的；程式碼質量是如何控制、程式碼分支如何部署，當時一開始的時候我們做了很多規範性的東西，但是發現光做規範是不夠的，規範是規範，實際操作是實際操作。這個過程當中，我們發現有一些管理是很難到研發團隊真正落實的，這個是做了很多工作以後我們遇到的瓶頸，我們規劃的事情往往不能夠很有效的推廣到各個研發團隊裡去。怎麼去落實，這個是我們近期建的一個DevOps的平臺建設。

整個 DevOps 建設平臺的目標，是希望通過DevOps 的整個理念，包括使用 Scrum 模型，建設整個研發能效平臺，實現從端到端的打通，提升整個研發效率與質量。整體而言，我們希望我們做的事情，第一能夠適配各個研發條線的各個技術棧，不管你是做什麼的，甚至做各種語言，我的相容平臺，可以相容所有的開發語言和開發工具。第二點我希望 DevOps 平臺建設搭建出來的東西，是簡潔應用的，不影響原有研發人員的研發工具使用和操作習慣，該做 Git 上傳程式碼都OK，他上傳之後，我們在平臺上做編譯和校驗。整體而言最後希望通過高效的手段，把整個研發過程完完全全構建出來，比較高效的實現整個研發過程，實現我們整個平臺的高效保障，這是我們跟博雲共同研發建設 DevOps 平臺的總體框架。

從底向上看，我們之前跟博雲合作過其它的一些技術，從底我們做相關資源的平臺整合，或者是去做應用。往上看從左到右，幾乎是整個研發的全過程，這裡不類舉了，每一個點都非常多，包括怎麼管程式碼、怎麼管需求、怎麼流水線、流水線出來之後度量怎麼分析。一個研發團隊，站在我的角度來說，我很關心比如說現在有50個研發專案組，怎麼看程式碼好壞、研發是不是達到既定的目標、怎麼看專案進度、原有的軟體圖是否能滿足我們要求，在做整個 DevOps 平臺的時候，我們通過這種建設，能夠在原有程式碼和專案的管理基礎上，為所有的專案組提供相關的服務。

再往上是整個大的門戶，所有需要看到的資料、所有度量的指標、所有的流水線進行哪一步、出現了哪些問題，通過整個平臺都可以看得到。

這個是專案裡面的截圖，整個研發流程，變得可視化了，而不是像以前的黑盒，通過傳統彙報的機制，專案進行百分之多少，寫一個日報，以前經常去做分解，去做 WBS 分解，現在通過平臺完全看得到流水線狀態，整個研發狀態、研發的人每天在做什麼事情，把流水線展開之後，看得到每一個階段編譯的時間是什麼樣的、涉及到的需求有哪些、最後是不是有出現問題、出現問題我的日誌是怎樣的，都可以追蹤出來。

平臺建好之後，能實現整個研發過程的資料可追蹤，原來研發是黑盒，現在從需求設計到最後的上線，每一個階段都看得到，而且是以版本作為一箇中心，從需求開始是哪個版本，已經確定下來，這個需求是誰寫的程式碼、哪個版本的程式碼、什麼時候構建的流水線、什麼時候做流水線的部署等等，我都可以追蹤出來，其中有一個階段出現問題，在測試環境發現一個 Bug 之後，很快就可以定義到這個程式碼是誰，在什麼時候寫的，根據哪個需求做開發，整體以版本做測試，有效提升研發過程和效率，很快能追蹤問題，發現問題，資料有了之後可以做度量。

有了資料之後，可以度量整個研發，以前最大的痛點，我們的研發團隊，來自各個不同行業，也有一些應屆畢業生，對整個度量自己心理都沒數，自己做的東西總覺得很辛苦。有資料之後，可以做度量，一方面所有的精細化資料，每一個程式設計師做什麼、研發工程師每天寫了多少程式碼、程式碼覆蓋率是多少、測試之後跑的結果怎麼樣，通過精細化管理，為所有研發測試人員提供改進手段和資料，通過 DevOps 平臺建設，使得原來手工做的東西全部通過自動化實現，做 DevOps 平臺的時候是和博雲聯合開發，各家做 DevOps 一定有自己的不同想法，我們需要跟各家的實際情況做定製，我們在東吳證券做了大量的指標計算也好，做流水線配置也好，這個是比較關鍵的，最後我們相對來說通過研發度量的資料分析，能夠比較準確實現研發過程管控。

這是研發度量裡面有指標做的截圖，做度量指標的時候，並不是 KPI 和度量做繫結，而其實是作為一個改進的引數，讓達到知道在工程維度有哪些地方做的不是特別好，專案維度哪個做的不好，整個開發的過程維度，整個團隊的協調組織架構過程，以及交付過程中有哪些改進，比如說都是敏捷類開發的，網際網路類的專案，我比其它的專案組有什麼不同，這個可以做度量和提升的點，我們整體會出一個大的檢視，讓大家知道我整個度量維度是怎麼樣的，最後 Scrum 結束之後，有哪些必須要做改進，這個才是關鍵的點。

平臺搭建完、度量完成之後，我們還做了一件事情，就是整個 DevOps 的成熟度評測，因為我們希望今年年底參加他們整個三級評測，最主要是以評促建，第二個是提質增效，通過外部視角看到我們研發平臺有哪些不足，和行業內、行業外有哪些差距，以提升研發的水平和質量。

04 總結展望

至於我們未來要做哪些事情，首先在平臺建設完成之後，大家原來用的工具很多，但是平臺逐步在用的過程當中，第一是自上而下的推廣，平臺讓大家全部使用起來，但是所有的反饋和持續的建設，一定是從下往上逐步反饋的，所以這個本身來說，就是一個持續改進的過程，我的 DevOps 平臺，一定要靠自己運轉起來的，不是靠供應商持續給我們提供服務，需要我們自己的研發人員，自己的管控人員持續做度量和分析，最終實現平臺真正規範的落地，這個才是我們精細化管理和研發效率提升最主要的方向。

在整個流程方面，我們在做整個 DevOps 的過程當中，發現其實還有很多流程是需要完善的，我們真正希望通過整個平臺實現一體化、一站式，最好是不要有人工介入的全流程的研發過程。

雲原生三件套，第一是雲、容器和雲管方面；第二是微服務、服務網格；第三塊是 DevOps。怎麼把三角套串起來，一方面是通過基礎資源的整合，另外是通過 DevOps 把流程串起來，還有微服務化，怎麼能比較有效實現服務的快速部署以及最後上線，對於研發隊伍和資訊科技比較關鍵。我們怎麼擁抱雲原生，接受雲原生，我們希望把內外網隔離，我的釋出往往是層層稽核，最後是手工部署上線，因為我們的資訊保安要求，包括系統可用性要求是非常高的，怎麼通過雲原生技術的手段，提升整個的程式碼質量、提升整個技術系統的穩定性，這個值得探索，券商端90以上的券商，系統的上線和部署是通過手工方式去做，我們怎麼通過雲原生能夠高效、高可用、可收縮，怎麼能夠實現系統的線和運營，怎麼實現 DevOps 的體系建設，這個是我們未來持續要做的。希望在座的各位將來能夠經常跟我們溝通，也希望整個行業在 DevOps 體系的交流越來越多。

以上就是我的分享，謝謝大家。