DevOps落地實踐及案例分享

轉載本文需註明出處：微信公衆號EAWorld，違者必究。

引言：

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

而DevOps被愈來愈多的金融企業所採用，來支撐軟件生產過程的數字化轉型，本文主要和你們分享在金融行業落地DevOps的一些坑，如何填坑以及一些心得體會！但願你們可以在本身企業中，找到適合本身企業的DevOps實踐之路！

目錄：

1、關於DevOps實踐的一些問題
2、DevOps在金融行業落地都有哪些姿式
3、DevOps在金融行業落地的套路
4、DevOps將軟件生產線數字化
5、總結一些DevOps最佳實踐
6、DevOps項目落地過程當中一些心得體會

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

來源：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年的成績：

代碼提交頻率：從以前的不固定到天天100屢次的提交
代碼集成頻率：從每個月1次到每15分鐘一次
部署流程：手工變成自動化
部署到QA和Perf（性能）環境頻率：從每個月1次到天天4次
部署到生產環境頻率：從每個月或每一個季度1次到每一個迭代1次
單元測試覆蓋：從沒概念到>90%

2016年的成績：

發佈到產品環境的頻率：從每一個迭代一次到天天至少1次
自動發佈的應用軟件數量達20個
一個應用軟件天天最多能夠發佈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落地經驗。


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


關於EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享。長按二維碼關注！