DevOps 落地實踐及案例分享

銀行業爲了應對業務的快速變化、互聯網層面不窮的業務形態和交易壓力，IT“雙態（或雙模）化” 無可避免，開始探索部分業務參考互聯網的方式引入分佈式架構，但對於銀行業獨特的強監管、高安全、強一致性的行業要求前提下，如何在業務發展、合規、IT 革新之間找到平衡？

而 DevOps 被越來越多的金融企業所採用，來支撐軟件生產過程的數字化轉型，本文主要和大家分享在金融行業落地 DevOps 的一些坑，如何填坑以及一些心得體會！希望大家能夠在自己企業中，找到適合自己企業的 DevOps 實踐之路！

目錄：

一、關於 DevOps 實踐的一些問題

二、DevOps 在金融行業落地都有哪些姿勢

三、DevOps 在金融行業落地的套路

四、DevOps 將軟件生產線數字化

五、總結一些 DevOps 最佳實踐

六、DevOps 項目落地過程中一些心得體會

1. 關於 DevOps 實踐的一些問題

我們從國際信息科學考試學會（EXIN）關於 DevOps 認證體系來分析，DevOps Pre-Master（DOPM）中包含了敏捷、精益、ITSM 和測試相關的內容，也就是說這四項其實是作爲了 DevOps 知識體系的基礎，其中敏捷、精益和測試是和軟件生產、開發工作 Dev 強相關，ITSM 則與 Ops 運維工作強相關。所以 DevOps 知識體系更像是對於以往 IT 知識的再次提煉和融合，不是一門新的技術。

DevOps 是什麼？又不是什麼？

• DevOps 是個開放的體系，從實踐中而來，並且還在不斷的發展，具體到某個組織也並沒有一致的套路，所以 DevOps 落地更多是因組織而異、因目標而異、因人而異

• 大家越來越意識到 IT 是個系統工程，要提高 IT 組織的績效，有很多好的通用的實踐，好的 DevOps 落地實踐會涵蓋 DevOps 最核心原則和模式，避免走不必要的彎路，有效地縮短個人和組織的學習曲線

• 在 DevOps 項目落地過程中需要培養和訓練全局的、系統性的思維認知能力，而非某些工具和命令的用法（原因是：原則和實踐是相對穩定的，而工具和命令的變化是非常快的），DevOps 落地不是單純的 CI/CD，也不是單純的 Jenkins + Ansible

DevOps 是自動化運維吧？不是做運維的爲什麼要學 DevOps？

• DevOps 是跨部門的合作，裏面涉及的部門和角色遠不止開發和運維（其他包括產品、需求、架構、測試、安全、項目管理等），所以 DevOps 不是自動化運維

• 但 DevOps 項目落地需要服務於組織目標，可以從自動化運維開始

講 DevOps 還是在講理論，會不會太虛了？

• 所謂 DevOps 落地本質上就是定義問題、識別問題可能的最優解、然後不斷實驗該解的循環過程。這裏不存在一個通用的落地框架，重要的是能理解問題的本質，培養自主解決問題的能力。任何別人家的落地都只是別人家的，企業需要發展出獨有的、屬於自己的落地實踐，沒人能替代（就像家長嘴裏的別人家的孩子，永遠無法成爲自己的孩子）

• DevOps 是高績效 IT 企業實踐的有機集合體。任何企業的 IT 都需要在競爭的環境下不斷提升自身的績效，以便有效創造客戶價值、最大化業務產出、減少浪費、提升交付速度和交付質量，並使企業在數字化時代擁有市場領先的 IT 能力。那麼，從這個意義上來講，只要是 IT 從業人員，學習和了解 DevOps 對組織和個人都是有非常有意義的

2.DevOps 在金融行業落地都有哪些姿勢

我們先看看我們對於 CICD 的定義：

• CI 持續集成，我們通常定義爲從代碼提交到編譯打包，再到 SIT 的過程

• CD 中的持續交付，我們通常定義爲從代碼提交到 UAT 的過程

• 但項目裏，沒有用 DevOps 做 CI 的項目，也可變相爲從編譯打包到 UAT 的過程

• CD 中的持續部署，我們通常定義爲從代碼提交到最後生產部署的全過程

• 但項目中，有可能變通爲從編譯打包到生產部署的過程

總結來看，項目結果不同，或者接入 DevOps 應用系統也有可能處於不同的階段，這造成了，CI/CD 的過程隨項目實際情況會有些差異。

DevOps 項目在售前、招標或前期階段，我們通常看到是小圈裏面的內容：CI/CD、自動化部署及回滾、與現有云平臺的接口、流程的圖形化編排調度等，但這些只是 DevOps 的內核，真正去落地一個 DevOps 項目的時候，其實你會看到外面大圈的這些內容，換句話講，需要梳理組織整個軟件生產的全過程！

姿勢一：小範圍 CI+CD，再全公司推廣

先看看 Capital one 的案例，美國第一資本金融公司，美國排名前十的銀行。

痛點：

2014 年當時，Capital One 的軟件開發實踐和很多傳統做法沒有什麼不同：大量外包，瀑布模型，季度發佈，手工流程，變更請求。在某次代碼檢查會上，大家發現一個測試失敗是由於某個 XML 文件裏的 tag 不配對造成的。按理說，這麼小的問題改了再提交就可以了。但是：開發工作是由另外一家公司負責，他們需要發起漫長的變更請求；代碼修改後的構建流程（編譯、測試、部署等）就需要至少 2 天時間。這個小小的問題讓 Capital One 的技術團隊開始反思他們的構建流程，並決定從這裏下手。他們從一個小的團隊開始實踐 DevOps，最終把時間從 2 天縮短到幾分鐘。於是，這個實踐逐漸在 Capital One 蔓延開來，所謂星星之火，可以燎原。

2015 年的成績：

1. 代碼提交頻率：從之前的不固定到每天 100 多次的提交

2. 代碼集成頻率：從每月 1 次到每 15 分鐘一次

3. 部署流程：手工變成自動化

4. 部署到 QA 和 Perf（性能）環境頻率：從每月 1 次到每天 4 次

5. 部署到生產環境頻率：從每月或每個季度 1 次到每個迭代 1 次

6. 單元測試覆蓋：從沒概念到 > 90%

2016 年的成績：

1. 發佈到產品環境的頻率：從每個迭代一次到每天至少 1 次

2. 自動發佈的應用軟件數量達 20 個

3. 一個應用軟件每天最多可以發佈 34 次

總結 DevOps 在 Capital one 的落地姿勢：先小範圍做全套，再全公司大範圍推廣。

某壽險也是用的姿勢一：他們是與基於 Spring cloud 的微服務體系架構一起引入 DevOps 的，原來的想法只是對於這些新的微服務的應用適用 DevOps，經過半年的時間之後，感覺還不錯，就將 DevOps 逐步向傳統單體架構的應用中去推廣了。表中的系統是目前已經接入到 DevOps 中的系統。對接的代碼庫有 svn/gitlab/bitbucket，介質庫是 Nexus，CI 和 CD 的流程目前還是做手工觸發，CI 集成了 Sonar 和 maven test 單元測試，cd 已包含測試和生產環境。組件包含：springboot、shell 腳本和 tomcat 3 類，主要是全量的部署方式。

再總結一下：先小範圍適用 CI+CD，它是現在微服務架構適用的，取得經驗積累之後，再大範圍的推廣。

姿勢二：先 CI，後 CD

我們看看中國銀行的案例

在項目之初，中國銀行首先對軟件生產的全流程進行了重新梳理和規劃，其中包含流程、規範、度量體系和反饋機制。

在實踐階段分了三步走，研發層面的持續集成、運維層面的持續交付，最終打通研發和運維實現 DevOps 全流程。

從試點效果來看，單就自動化部署層面就比之前提高了 2-5 倍的效率。並且在軟件質量和規範落實層面有了長足的進步。

再來一個以姿勢二落地的，某國家政策性銀行。

它的科技局下屬研發中心和運行中心是分開的兩個大部門，兩個部門之間的紐帶就是介質，但之前代碼基線與生產環境的介質版本一直對不上，這對生產的 BUG 修復、災備部署都形成了很大困擾，所以它的研發中心引入 DevOps 是希望能形成統一的軟件出口，能夠將需求、代碼、配置、介質控制在同一個基線上。所以他們做法是先做 CI，並且並行配合 maven 的框架推廣及 CMMI4 的落地實施。但項目到了二期，它要引進建行建銀科技的新核心，一是新核心短時間內的多版本在多個測試環境的部署，二是配合改造的 69 個業務系統短時間內也會有很多版本要快速部署，進行集成測試，這就要求必須有自動化部署的工具纔行。所以 DevOps 二期的重點就定在了 CD，主要是配合核心及配套改造系統提測後的快速自動化部署。

所以總結一下，DevOps 落地的第二個姿勢：通常都是先由研發部門主導做 CI，之後再推廣 CD，最後將兩個流程串起來形成 CI 和 CD 的全流程。

姿勢三：先 CD，後 CI

這是一家地方商業銀行，也是因爲今年要上新核心，並且伴隨新核心，有 5 個系統要重新建設，110 套系統要配套改造，行領導提出的目標：在 9 月 8 日上線時，利用 DevOps 做一鍵式的統一部署！所以項目一期的重點就放在了 CD 上，短期目標是滿足 110 多套系統的短期大量版本的提測後的自動化部署，最終目標，是要將 1+5+110 這些系統能夠可視化的一鍵式部署。項目的二期重點，是在 CI，配合諸多研發管理的落地實施，全流程的應用和推廣以及自動化測試的接入。

3.DevOps 在金融行業落地的套路

套路我總結了五步：確定目標、選好姿勢、梳理全流程、制定規範、最後分步實施。我們細看一下這五步：

第一步：確定目標

示例一：

這是農行對於 DevOps 設定的目標：1 個平臺、能夠連接開發、測試、運維 3 個角色，打通需求、開發、測試、部署、運維 5 個環節。

示例二：

我們再看看招商銀行設定的目標：DevOps 是作爲打造精益研發體系的一個重要組成部分。

第二步：選好姿勢

• 第一種姿勢：小範圍 CI+CD，之後全公司推廣 CI+CD ， 並打通全流程

• 第二種姿勢：先 CI，後 CD，打通全流程

• 第三種姿勢：先 CD，後 CI ，打通全流程

第三步：梳理全流程

示例一：

這是對一家商業銀行全流程的梳理，以及 DevOps 需要集成的 IT 系統，如項目管理系統、JIRA 以及測試管理系統。

示例二：

這是招商銀行的全流程梳理，將 DevOps 平臺切成了兩個平臺協同工作平臺和持續交付流水線平臺。

示例三：

以上是農行的全流程梳理方式。

第四步：制定規範

在將整個軟件生產全流程梳理完之後，會很對 DevOps 及各原有 IT 系統的集成界面和分工非常清晰。接下來就要進行第四步規範的梳理和制定，規範包含哪些呢？

• 開發規範

• 持續集成規範

• 持續部署規範

• 持續交付規範

• 介質管理規範

• 文檔命名規範

• 開發分支管理策略

• 測試管理規範

• 運維管理規範

• ……

那規範制定的目的是什麼呢？

• 有效管控軟件生產線上的各個活動和環節

• 建立統一質量和衡量標準

• 軟件生產活動能被持續度量、反饋、優化

• 通過 DevOps 進行有效落實

簡單來講，沒有規範的制約，沒有統一標準，大家各做各的，DevOps 項目不可能成功。

第五步：分步實施

接下來，就是第五步，要具體的落地實施了，但也要有前有後，分輕重緩急。我們建議調些試點項目來，如何來調呢，原則是啥？

DevOps 試點項目的選擇建議原則：

• 基於互聯網渠道，需要快速迭代的項目

• 需求、產品、開發、測試、運維都在一個團隊的項目

• 有一定腳本化或 CI/CD 積累的項目

• 基於 JAVA Maven 的項目

DevOps 試點項目執行原則：

• 制定規範與試點項目執行並行，來驗證規範可落地、可實施，而非空中樓閣

• 通過試點項目總結出類似項目推行 DevOps 的規定動作，如：Demo 腳本、CI/CD 流程、自動化測試腳本、Maven 二方庫和三方庫的管理經驗等等

• DevOps 與試點項目團隊混編，定期舉行回顧會，鞏固成果，總結教訓，關鍵——肯定成績和收穫

DevOps 試點項目執行的苦惱：一個巴掌拍不響：

• 需要堅持對目標的執念

• “兩口子過日子” 理論

4.DevOps 將軟件生產線數字化

從橫向角度來看，DevOps 產生的數據可以分 3 個部分：

管理數據、開發數據和運營數據，其實這些數據是涵蓋了軟件生產的全過程，我們可以通過這些數據或直播，來反哺到我們的生產過程，優化我們的不足。

我們從另一個角度 DevOps 的質量視圖、從縱向角度來看，我們也可以從週期、效率、治理和技術的角度來去制定指標考覈。

5. 總結一些 DevOps 最佳實踐

持續集成的原則

• 鼓勵開發人員在開發分支上頻繁的提交代碼，隨後觸發 CI 流程，在 CI 過程中可以加入單元測試和代碼質量檢查等動作，這樣產生代碼衝突的幾率會下降，並且代碼質量也會提高的；

• 在下班之前，構建必須處於成功狀態，原因是你的代碼在第二天有可能是其它同事開發工作的基礎，如何無法保證構建成功，會影響其它的人工作質量和效率，團隊氛圍也會產生壞的影響；

• 讓開發環境上快速體現最新程序包

• 讓程序、配置、數據分離，其實現在好多的單體應用開發時，是將程序、配置、數據裹在一起的，改一處，要解決一堆的依賴，改一處，牽扯到很多地方都要做更新，這些降低了版本迭代的效率，並且很可能會出現遺漏

• maven 模式下，pom 依賴儘量不要用 system 本地依賴模式，而是將二方庫和三方庫依賴到統一的類似 Nexus 介質庫，整個組織一份，來屏蔽本地 jar 依賴差異導致的編譯錯誤。

持續集成的最佳實踐

• 構建過程，建議等待構建的結果，不要同時做其它的事情，尤其是構建失敗之後不要提交新代碼，這樣很可能會錯上加錯，最後不知道到底是誰的錯，這些錯誤的回溯會產生很大的成本。

• 提交之前在本地運行所有的提交測試

• 提交之前請更新本地代碼，保證代碼是最新的，衝突解決了，再提交

• 記得更新數據庫、配置文件等

• 等構建成功後再繼續其他工作

• 下班之前，構建必須處於成功狀態

• 以十分鐘爲界限，如果代碼提交後構建錯誤，十分鐘之內無法解決問題，需要將新代碼撤回，否則可能會影響其它同事的工作。

自動化部署的原則

• 原則 1：確保從開發、各類測試到生產，使用相同版本的中間件和操作系統，保證從操作系統、到補丁包、到應用運行環境基線是一致的

• 原則 2：同一套腳本，解決各類環境的部署問題，不要試圖通過腳本來解決環境的差異性，因爲環境的差異性本應該是不存在的，否則改了腳本，之前的各個環境還需要做腳本的迴歸測試

• 原則 3：部署之前，事先設計回滾與零停機發布的策略

• 原則 4：全量發佈優先，儘量不要用增量發佈，因爲引入增量發佈，就會引入手工操作，人工去選擇哪些做增量

• 原則 5：詳細記錄部署活動的整個過程

自動化部署的最佳實踐

要做到自動化部署，要確保自動化部署的成功，最最重要的關鍵爲：保障一致性！將要部署的各個環境一致；在各個環境執行的部署腳本一致；要部署的安裝包也要一致！

• 從提測之後，所有環境運行的是同一個介質包，不要在 SIT、UAT、準生產和生產等環節重複的打包

• 保證各個環境的操作系統、補丁和軟件運行環境的基線一致；

• 保證使用同一的二方和三方庫依賴，推薦 Nexus

• 關於配置文件，建議: 配置文件與代碼的版本保持一致

• 配置項清晰、規範、統一命名

• 配置項模塊化、且封閉

• 每個配置項都是唯一的，避免顧此失彼

• 避免過分設計，儘量簡單

• 建議逐步過渡到 Apollo 這樣的統一配置中心，以 key/value 的形式管理各環境的配置項

6.DevOps 項目落地過程中

一些心得體會

關於 DevOps 項目的複雜度，我畫了一個矩陣圖，希望與大家形成共鳴：

圖的 X 軸是軟件生產的全流程，Y 軸是 DevOps 要集成的各類 IT 系統，Z 軸是要推廣的各個項目，從這個圖可以看出，要做好 DevOps 落地，複雜度還是相當高的。

DevOps 項目落地，我自己總結了一套扁擔理論：

• 這條扁擔就是軟件生產的全流程，是整個項目的骨架，需要事先梳理全流程，並打通工具鏈，制定各類規劃和規範

• 扁擔一頭挑着自動化持續集成，各項目組件構建的調研、設計、開發、適配，從標註化到腳本化，最後自動化，並落實開發規範

• 扁擔另一頭挑着自動化部署，各項目組件部署的調研、設計、開發、適配，從標註化到腳本化，最後自動化，並落實部署和運維規範

但 DevOps 項目雖然落地困難，無論從管理者層面和一線人員層面也確確實實能給金融起來帶來價值：

對於管理者：

• 將軟件生產的各個管理環節前置，儘早發現軟件質量問題，從而降低缺陷的解決成本和對生產帶來的影響；提高軟件產品的質量

• 縮短軟件產品的生產週期，軟件產品儘早的投產使用，給業務帶來價值

• 實現從業務需求到產品上線的里程碑管理和成本統計

• 實現需求、開發任務、代碼之間的閉環關聯

對於一線人員：

• 引入流程化和自動化等手段，提高軟件產品的生產效率

• 保證環境一致性、腳本一致性、介質一致性，縮短各環境的發佈部署時間

• 在軟件產品的生產過程中，引入標準和規範，從而規避手工操作帶來的混亂和風險

希望大家能夠通過本文，瞭解一些 DevOps 在金融行業落地的套路和最佳實踐，能夠找到適合自己組織的 DevOps 落地經驗。

精選提問：

問：開發規範、持續集成規範、持續部署規範、持續交付規範、介質管理規範、文檔命名規範、開發分支管理策略、測試管理規範、運維管理規範，這些規範有好的實踐嗎？

答：這些我們在項目中已經積累了好多規範，並且在基本所有客戶也都有自己先行的一些規範，只不過是不全面或者沒有落實。我們是希望和客戶一起 DevOp 涉及到的規範都梳理一遍，通過 DevOps 能過落實下去。當然這個過程也是持續規範、持續遞進的過程，不太可能一下爬到珠峯頂。

關於作者：八爺，普元架構師，擅長 DevOps、基礎架構層 IaaS/PaaS / 虛擬化、系統分析和架構分析；參與九江銀行持續集成項目、國家開發銀行 CDP 二期項目、中投移動辦公平臺項目、山東城商聯盟服務治理項目諮詢工作。

出處：https://www.sohu.com/a/330487367_671228

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/QaalRYLp4wynmRdn63g-_w