本文根據〖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的時候是面臨著運維壓力，然後說要改，銀行這邊壓力點是在開發部門，並且是業務給開發端的壓力。爲什麽業務會給開發端這些壓力？原因是多方面的，其中肯定是業務需求旺盛和或業務交付速度不夠快。
假如說是這樣的情況，對比同業交付速度比較快，而銀行業務略微慢一些。這個時候壓力就會出來，交付的壓力會傳導給誰？肯定是研發中心。我們就面臨著所有的整個業務，這時，運維方面還沒有傳到到呢、或者感受的比較小。
>>>>
2020年4月17日，北京，Gdevops全球敏捷運維峰會將開啓年度首站！重點圍繞數據庫、智慧運維、Fintech金融科技領域，攜手阿裏、騰訊、螞蟻金服、中國銀行、平安銀行、中郵消費金融、中國農業銀行、中國民生銀行、中國聯通大數據、浙江移動、新炬網絡等技術代表，展望雲時代下數據庫發展趨勢、破解運維轉型困局。