拉動DevOps持續交付的三匹馬——快速交付實踐總結與思考
本文節選自《金融電子化》2018年3月刊
作者：中國銀行軟體中心 付大亮?
編 者 按
本文以轉型過程中各種實踐為基礎，結合筆者思考，探討工藝、工具和技術如何相互配合支撐DevOps持續交付。
背景：中國銀行軟體中心先後通過ISO9001、CMMI3、CMMI4、ISO27001認證，形成了完整的管理體系，為交付高質量的軟體奠定堅實基礎。軟體中心項目採用瀑布開發模式，按批次投產、批次時間點在每年批次計劃中確定。隨著互聯網金融、利率市場化等環境變化，軟體中心引入敏捷，經過兩年多努力，全流程試點項目交付速度提高5倍。敏捷試點成功的同時，也遇到進一步提升的困境。
問題：交付周期難以進一步壓縮；適用敏捷項目實施方式的產品範圍有限，很多傳統銀行IT系統難以敏捷；隨著敏捷後版本數量增加，維護人員壓力激增；一些項目採用敏捷，裁剪了很多瀑布模式下的控制點，產品質量風險升高。
實戰經驗：為進一步提升交付能力，軟體中心引入DevOps。
車夫：組織方針、目標
車夫就是組織管理方針、目標，負責統一思想，引領方向，形成企業文化。管理方針為工藝、工具和技術的篩選、引入、整合和優化指明了方向。工藝、工具和技術這三匹馬向上支撐組織方針、目標，實現優質高效；向下沉澱企業文化，凝聚員工力量。對於社會各行業，響應總理所號召「大眾創新、萬眾創業」；對於具體一個組織或角色需踐行「工匠精神」，立足本職，精益求精，這是創新的辯證統一。DevOps是一種管理和IT技術相結合的創新，在不同組織之間、在一個組織內外有著不同的視角和側重點，也有著相同之處。不同組織因目標、方針和所處環境的不同， DevOps實踐側重點、開展方式也不完全一樣；同一個組織，因角色分工不同，DevOps實踐側重點、開展方式也不完全一樣。但DevOps是在IT領域改進；都是為了支持業務發展，提高IT部門交付能力； DevOps的指導思想、改進方法和專業領域又有很多相同之處可以借鑒。這些相同點和不同點都需要在組織方針、目標指導下，有目的、有機會的改進，才能為支持組織目標達成。
第一匹馬：開發工藝、管理流程
三匹馬中的第一匹馬是工藝流程。大型項目開發過程是一個高度協作的過程，必然有流程規範。工藝流程是拉動快速交付的第一匹馬。這匹馬解決了複雜任務分解的問題，解決了人員協作、職責分工的問題，給出了完成任務的工作路徑、交付方式和驗收標準。在敏捷引入初期，筆者認為CMMI、ISO太重，應該逐漸被敏捷替換。但經過兩年多敏捷轉型實踐，逐步意識到敏捷宣言和CMMI、ISO並不衝突，敏捷宣言指導開發團隊應對需求快速變化，CMMI、ISO指導組織構建開發團隊運行環境、構建開發工藝流程以及構建質量保證體系。兩者結合才能為組織創造最大價值。敏捷轉型初期，我們將敏捷試點項目放在獨立於組織規範要求的理想環境中，加速敏捷引入。中期，我們將敏捷思想融於組織管理流程，將敏捷思想在更大範圍內應用，以此來優化工藝流程，同時讓阻礙交付速度進一步提升的因素更為突出，為下一步優化提供輸入。後期，工藝流程設計從批量交付向單一功能快速交付轉變，即精益思想中的單件流，每次交付都給用戶提供一個完整、可用的功能。工藝流程的優化在一定階段能夠提升交付效率和質量，當規範、要求增加到一定數量時，由於規範、要求本身複雜性增加，落地執行就會變得困難，效率和質量也不會明顯提升，甚至因為規則過於繁瑣而導致執行不完全到位的情況出現。為避免這種情況，需要技術架構解耦；用工具承載流程、規範要求，進一步提高團隊執行力和執行效率。
第二匹馬：DevOps工具
第二匹馬是工具，它與第一匹馬互為表裡。在軟體開發過程中，軟體發布作業流上的工作可以分為三類：第一類是為交付物增加價值的工作；第二類是支持保障性工作；第三類是浪費，如頻繁交接、內耗、返工等。第二匹馬通過工具和自動化技術提高這三類工作的效率和執行精確度，把員工從繁重的機械勞動中解脫出來，執行創造性、開拓性的工作。如軟體開發中，編寫代碼是增加價值的第一類工作；檢查規範落實情況，集成組件、部署、驗證屬於第二類工作；BUG修復、反覆協調屬於第三類工作。引入eclipse等IDE開發工具可有效提高第一類工作效率；引入持續集成、自動部署、自動化測試等工具接替手工操作以提高第二類工作效率。第三類工作有技術因素和非技術因素：技術因素可以通過改進工藝和工具來解決；非技術因素需通過企業文化、工藝改進、工具提升綜合處理。
軟體中心集成了Jenkins、Checkmarx、Findbugs、robot framework、maven等工具實現DevOps發布流水線及相關質量檢查，在提高速度的同時，控制質量風險。如圖1所示，工具通過調度連接實現自動化，通過匯總運行數據，實現數字化、可視化，構建多重反饋環。工具執行速度往往是人工的幾十倍、上百倍，這裡主要說明三點。
圖1?DevOps開發側承載持續發布的環境拓撲圖
一是工具不僅適合承擔重複性工作、傳輸記錄性工作，還適合做檢測類工作。可以把管理規定中明確的部分通過工具去執行和落實。以此來提高效率，降低人力成本。長遠來說還能不斷促進團隊提升執行力。
二是軟體開發的工具要成體系，集成到一個作業流中——DevOps中叫「發布流水線」，像管道一樣，有一個入口、一個唯一正確出口和若干異常出口。「正確出口」指所有檢查都通過後發布流水線結束的位置；「異常出口」指未通過檢查導致發布流水線終止的位置。發布流水線以「標準化、工具化」為基礎，利用自動化方法整合零散的工具，降低工具使用難度、提高效率、嚴格落實既定工藝流程。「標準化、工具化、自動化、數字化、可視化」就是軟體中心DevOps建設的指導思想。
三是因專業分工、信息安全等因素，工具一般是在不同時期，由不同的人員引入。與交付相關的工具，需要具備集成到發布流水線的能力。不能集成到發布流水線的工具會增加使用成本，降低交付速度。
第三匹馬：架構技術
引入敏捷、持續集成、DevOps等在互聯網公司興起並取得成效的工程方法，有時還達不到互聯網公司的發布速度。原因有多方面，如銀行老中青多代技術標準並存，難以自動化；產品產生於C/S架構時代，產品/模塊間耦合大，難以獨立發布；銀行業安全合規要求高……為了支持快速交付，需要向分散式、微服務遷移，還需要灰度升級、自動故障隔離等IT基礎架構能力控制快速交付帶來的風險。這就是第三匹馬——軟體開發、運維、質量檢測相關的技術。技術是硬實力，是工藝流程設計、工具引入、整合的基礎。筆者所在IT部門主要支持傳統銀行參與互聯網金融競爭，這裡技術指能夠支撐優質、快速交付軟體功能的相關技術。這些技術允許大的需求拆成小的「故事」（敏捷術語，一種軟體需求形式），實現快速交付；降低自動化檢查、自動化驗證、自動化部署落地難度。技術棧的特性和工具集差不多，一般有1+1>2的效果。如雲技術就是上接用戶場景，下接硬體設備、成體系的技術集合，無論是影響力還是實際效果都受到廣泛認同。整合後的技術體系為開發團隊提供全套服務，而不要開發團隊詳細了解細節，使開發團隊可以專註於業務需求交付。近年軟體中心主要研究X86平台上分散式相關技術，整合Dubbo、spring、mybatis、zookeeper等形成「E中銀」技術體系，如圖2所示。相關研究成果獲得了2015年銀監會二類課題。
圖2?E中銀架構示意圖
《金融電子化》新媒體部
主任 / 鄺源 編輯 / 潘婧
TAG:金融電子化 |