大家好，今天與大家分享的內容是 DevOps 在國有大型商業銀行的規劃與實踐，審視從國有大型商業銀行視角看一下 DevOps 怎麼樣規劃與實踐。分享內容大致是這樣的：
分享概要1、目標和背景2、體系架構3、三條主線，即：工具、流程、規範4、總結
一、背景與目標
在去年下半年和今年上半年，我行提出了數字化轉型戰略。今年上半年的機構體制改革已經完成了，業務和科技部門在組織結構上進行了相關調整。
金融行業在研發過程中，經常提到的是雙模研發，其中在核心繫統上還是要用原來傳統的方式來進行研發。
在業務角度，核心系統不會有那麼大的變化，相對變化比較大一般都是掌銀、網銀及新興業務方面，所以，在核心繫統上採用穩態研發、瀑布式的或者接近瀑布式的方式是一個非常理智的選擇。
而在其他方面，比如說網銀掌銀，市場變化壓力非常大，如果不快起來，業務也會讓你快起來，企業也會讓你快，還要保持四平八穩，那是不想幹了，是吧！
今年 6 月份，研發中心與信通院在 DevOps 方面進行共建。我們 DevOps 方面的目標可以簡要概括為“1、3、5”：一個平臺（DevOps），連接三個角色（開發、測試、運維），打通五個環節（需求、開發、測試、部署、運維）。如此構建農業銀行研發中心的 DevOps 體系。
二、體系框架
體系框架方面，與大家說體系框架之前，把我最深刻一個體會與大家分享：那就是“零”。
“零”是什麼呢？其實對 DevOps 內容來說，大家覺得 DevOps 是幹什麼的？對於企業來說：DevOps 也好、敏捷也好、之前的 CMMI 也好，都只是企業實現目標的一個工具和手段。
有段時間 CMMI、DevOps 或者敏捷，相關內容在企業進行推銷的時候，如果 Get 到企業的管理訴求、解決企業的痛點問題，其實叫 DevOps 還是什麼都無所謂，尤其對大企業來講，這個是最最重要一點。
還有一點我需要跟大家特別掏心窩的說一下，DevOps 是什麼？在學術和交流角度務必要清楚；但是，在企業角度最重要的是它能給企業帶來什麼價值。
DevOps 是什麼？拿這個圖來說。大家看像是一個房子。DevOps 就是裝修隊如何來裝修你的房子。DevOps 在傳播過程中，首要提到的是拆牆（如：拆除研發與運維的牆、業務與技術的牆，當然也有企業與用戶的牆）。讓大家能更好的溝通和交流，快速的實現價值的交付。
這兩年，我們科技圈的 Dev 和 Ops 是不夠，視野太狹窄了。其實至少要到科技和業務，拿銀行的詞而就是痛毆“業技融合”來快速響應市場的需求。
以下幾點很重要：有的企業能拆牆，有的企業只能從牆上開一扇門，有的企業最多能開一扇窗，有的企業可能只能鑽一個孔。
對於實際執行者，需要考慮一下，適合企業現狀的是拆牆、建門、開窗還是打孔，這個是最關鍵的一個點，否則大家就是在聊 DevOps，聊 DevOps 而不是在做 DevOps。
在做 DevOps 時一定要記住：你是在幹嘛？拆牆、開門、開窗、還是打孔。如果孔都打不了，那 DevOps 就展示不要想了，先等等或嘗試推動。
我們剛開始做敏捷只是開發過程敏捷，有些情況下只能做到這個範圍，甚至有一些團隊這都做不到。需要根據實際情況，下面做的內容是我們的一些探索與實踐，站在研發中心角度，我們怎麼來拆牆，開門，開窗打孔。
首先是體系框架圖。在信通院 DevOps 體系規範裡面有這樣一個體系框架圖。我們也基本上延用了相關內容，但是跟它比有一些特色。因為我們企業的形式其它企業不一樣，我們是一個研發中心，就是上面有業務部門，下面有運維部門。
例如：
- 在我們的規範中叫組織文化。原版體系架構叫企業文化；
- 工具裡面一站式工具平臺，按照我們的工具平臺寫的；
- 再下面是流水線，我們是從提交、一直到部署和運維，而不是更長的一個流程；
- 隨後是技術架構、應用架構，我們是有使用自己的 Saas，IaaS，PaaS。
通過體系框架的比較，大家可以看到，我們跟業界方式方法基本一樣，同時，根據相關實際情況進行了一些改造和優化。
其次是三條主線，工具、流程、規範。
- 在工具方面，我們要建設統一的平臺：DevOps 集成平臺；
- 在流程方面，建設持續交付流水線、推進自動化測試、完善運營監控；
- 在規範方面，建立一個質量視圖和打造 DevOps 組織規範。
三、實施路線——工具部分
工具方面：我們會根據規劃進行一個逐步收斂，比如：配置管理工具、代碼白盒檢查、構建和發佈工具等。
同時，進行管理鏈和開發鏈的一體化，測試鏈與開發鏈一體化，形成研發側的工具鏈。
之後，就是研發態和運營態，對應就是研發工具鏈和運營工具鏈。形成統一的 DevOps 平臺。
三、實施路線——流程部分
流程方面：有了工具，還需要用流程進行規範。比如：持續交付的流程，大家都是差不多，從業務需求，通過編碼構建然後一直到測試環境，一直部署到生產部署。
這裡有一點需要說明，部署到生產環境需要符合銀保監會相關要求。測試方面、運營監控方面處理思路與此類似。
四、實施路線——規範部分
規範方面：規範部分可能這裡面比較重要的就是質量視圖，大家都知道 -PDCA。
我們統一的過程管理整體視圖是這樣的，質量視圖是分層級的，例如管理類視圖，首先是製作“勢能大”、對其它工作有指導作用的領導層使用的報表，通常是與考核和績效有關的報表和指標。
在開發類視圖中，大部分是技術方面的。比如配置管理工具、代碼掃描工具、安全掃描工具、構建工具等，它們為項目組、團隊來提供運行情況的信息。旁邊，有生產環境有運營鏈對應的報表和指標。
質量體系中質量視圖有指標，大家都關心指標。我們做了大致的分類，預計會形成這樣一個視圖，橫向是我們的指標所產生的階段，縱向是指標的大分類。比如說週期，會有什麼樣的指標，跨的範圍是什麼樣的，效率會在哪個方面，不同顏色表示著不同的關注程度。有些指標可以促進系統內部改進和系統之間對比讓大家相互促進。
如果把整個圖畫出來、把所有指標全都標出來肯定是比較大的圖。可以把一些，最後關注點裡面的指標先列出來，大家能看到我們關注什麼，並且關注是在什麼階段。
這是我們的儀表板樣例，包括週期、項目數量、交付的時間、以及所屬部門等等。通過度量體系和相關儀表板。我們可以滿足領導層進而是各個成績瞭解實時情況。
下面說談一下 DevOps 組織規範。正中間是 DevOps 的文化建設和體系建設。文化建設又包含了我們的一些制度標準、敏捷培訓體系、指標與監控等方面內容；技術體系方面包括 DevOps 集成平臺、持續交付流水線、分層自動化測試體系、監控運維分析、統一質量視圖等。
它們共同作用、在技術方面有 DevOps 平臺，在文化建設方面有標準。還需要定期的外部和內部自檢、評價，逐步建立我們 DevOps 的相關規範。
六、總結
輸出成果方面，建立農業銀行的 DevOps 成熟度評價體系。可以評估某個研發系統的 DevOps 成熟度，這個大家可以對比一下原來的 CMMI，我們做這個東西更多是讓內部有一個評價、評估和考核方面的需要。
在考核體系方面，主要考核內容是交付週期，什麼時候接到業務需求，一直到什麼時候交付給業務。
今天與大家交流了最開始的企業使用 DevOps、敏捷等最重要的“零”；之後，介紹了 1+3，即：一個體系框架加上工具、流程、規範。希望能對大家有所幫助。
閱讀更多 大家一起學編程 的文章
