本文根據〖2019 DAMS中國數據智能管理峰會〗現場演講內容整理而成。

講師介紹

姚元慶，中國農業銀行研發中心資深專員，具有十余年金融業軟件研發、項目管理經驗。長期致力于組織級項目管理、PMO建設、敏捷研發規劃，以及作為教練為項目提供支持等工作。

大家好，今天與大家分享的內容是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，即：一個體系框架加上工具、流程、規范。希望能對大家有所幫助。

>>>>

Q&A

Q1：我們公司也是大型國企，現在領導已經確定了要上DevOps，但因為我們有眾多的外包合作方。我們希望借助這個平臺和工具鏈，把很多項目外包模式逐步轉成人力外包。在這個中間，有您里面提到的組織文化建設和規范推動的過程，所以我就想慢慢向合作方推或者是要改變很多不同的現有工作模式，有沒有什么好的建議？

A：領導為什么要推DevOps？解決了企業的一個什么樣的痛點？這個痛點是不是真的痛或者是癢點，大型企業的關注點的可能比較多，我們要分清，是否真的要解決問題和解決什么問題才去做DevOps。

外包是DevOps需要注意的一個坑，我個人覺得的重要的是，你要怎么來考慮激勵他?外包人員如何融入？這些是跟企業內部員工完全不一樣的。你把這個方面解決一下，人員激勵能夠融入團隊里面來，做到這點才能解決你那個問題，逐漸把供應商的技術能力固化到你們企業里。激勵方面才是最重要的事情，要不然也不要考慮其他的了。

想掌握的產品，跟你的技術能力是要匹配的，我們的特點是大型商業銀行，需要承擔社會責任、需要遵照銀保監會相關要求，我們會一定會滿足“風險可控”，同時也會進行“make or buy”分析，采取恰當的方式。

Q2：您覺得市場上隨著DevOps不斷發展，是如何改變開發人員和運維人員之間的一種合作方式？

A：開發人員和運維人員想改變的就一個，原來大家目標是不一樣，開發受業務要求，要盡快發布新的功能，運維那邊希望盡可能穩定，別出事，目標不一致導致原來協作方式出現那堵墻。

如何讓他們目標一致協作起來，根本原因蠻簡單，讓這堵墻沒有，原來是因為目標不一致產生的墻，現在讓目標一致。

怎么一致？就是涉及到企業文化、團隊組成、考核，才可能把這墻打破。如果只是通過工具，剛開始是孔，把信息傳遞過去，原來信息都傳遞不過去怎么弄？

現在通過工具孔，把信息傳遞過去之后，逐步讓墻變得透風了，慢慢建窗、門。慢慢的推倒這堵墻，一定要讓大家目標一致。

這個雖然看起來虛，但就是根本。協調目標這個事情是一個大手筆，通常需要改變組織結構。

Q3：我比較好奇，在大型金融機構里頭，目前在機構里推DevOps都是研發機構發起的，為什么不是數據中心發起呢？

A：這個問題真的是一個好問題，Patric發起DevOps時是從一個運維側逐漸發展起來的。大家做所有相關實踐，大部分都是從運維角度考慮。這個沒錯，那么為什么銀行這邊大部分是從研發這個角度來？我個人理解不一定對，是因為整個銀行壓力傳導點與前面說的情況不一樣。

剛才說DevOps的時候是面臨著運維壓力，然后說要改，銀行這邊壓力點是在開發部門，并且是業務給開發端的壓力。為什么業務會給開發端這些壓力？原因是多方面的，其中肯定是業務需求旺盛和或業務交付速度不夠快。

假如說是這樣的情況，對比同業交付速度比較快，而銀行業務略微慢一些。這個時候壓力就會出來，交付的壓力會傳導給誰？肯定是研發中心。我們就面臨著所有的整個業務，這時，運維方面還沒有傳到到呢、或者感受的比較小。

?

?

總結

以上是生活随笔為你收集整理的金融科技：中国农行研发中心DevOps规划与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。