真實的DevOps落地，應該是這樣的 ↓

導讀

數字化轉型浪潮下，金融機構的科技部門在自身組織與企業文化背景下，是否适合做 DevOps？是否能夠平穩落地 DevOps？如何在滿足監管合規的前提下，利用 DevOps 更快更好的響應業務？

本文圍繞傳統金融機構是否需要DevOps、傳統金融機構落地 DevOps 的難點及落地路徑等内容，幫助傳統金融機構理清DevOps落地需要考慮的問題，以及為其啟動 DevOps 建設提供建設路徑與實踐經驗。

01 傳統金融機構是否需要DevOps？

傳統金融機構的典型研發流程是怎樣的？

大緻流程如下：

業務團隊

• 角色定義：相對于科技團隊之外的業務團隊，需求提出方，如銀行的網金部、券商的固收部等。
• 主要工作：通過線上OA/線下Excel/線下會議，向科技部門提出原始業務需求。

需求/架構團隊

• 角色定義：科技部下屬的需求團隊或架構團隊，可能承擔着業務需求拆分、重要系統架構選型等工作。
• 主要工作：業務需求評審，拆分成若幹系統需求，可能這時已經明确大緻的上線時間。

開發團隊

• 角色定義：科技部下屬的開發團隊，如某系統開發組、某項目組。該團隊可能是1-2個甲方項目經理和一支項目/人力外包服務隊伍組成。
• 主要工作：根據系統需求，進一步完成詳細的需求、設計工作，經确認後進入開發測試階段；（做的比較好的，BA階段測試團隊也已經開始介入）。

測試團隊

• 角色定義：科技部下屬的測試團隊（可能是獨立測試團隊資源池化管理，也可能是每個系統開發項目組中有專門幾個人）。
• 主要工作：以資源池抽調資源到不同項目，或針對某系統/項目提供相對固定的測試工程師團隊以完成相關的工作。另外，性能測試團隊也有可能是共同團隊。

運維團隊

• 角色定義：科技部門下屬的應用運維團隊，可能會存在部分外包人員做輔助技術支撐。
• 主要工作：負責應用的生産環境部署、更新及日常運維。

整體來看，傳統金融機構的典型研發流程很多時候其實并不那麼”靈活”，而是傳統的瀑布模式居多，甚至很多時候，還會有一些臨時插播進來的緊急需求（是需求，不是缺陷）。

我們能通過DevOps去解決什麼問題？

在現有的流程下有哪些問題，我們可以從研發過程相關的部門/團隊的職責邊界以及對應的工作内容、關注點上來看：

業務部門

• 業務需求何時能夠上線？>>>業務響應速度/及時性。

需求團隊

• 業務需求拆分成系統需求後，如何進一步做準确的系統需求拆分與分析？>>>需求分析管理。
• 系統需求完成分析後，後續設計/開發工作是否能夠滿足進度要求？>>>開發進度。
• 系統需求完成分析後，後續測試工作如何組織，以及組織的如何了？>>>測試品質。

• 需求/任務開發進度？>>>業務響應速度/及時性。
• 需求分析是否到位？>>>需求側協同 & 需求分析完整性、準确性。
• 基礎工具鍊是否具備、功能完善、易用？>>>研發基礎設施完整性、易用性。
• 代碼品質如何？>>>靜态代碼掃描、人工代碼評審、結對程式設計。
• 功能/性能測試團隊是否能夠充分了解需求？>>>測試準确性
• 開發過程缺陷跟蹤情況如何？缺陷送出情況、缺陷修複情況、缺陷資料統計。

• 測試計劃安排情況？>>>測試管理
• 功能/性能/安全測試團隊是否能夠充分了解需求？>>>測試準确性
• 開發過程缺陷跟蹤情況如何？測試過程跟蹤、缺陷送出情況、缺陷修複情況、缺陷資料統計。

• 應用部署包（含部署腳本、部署說明書）是否完整、易用？>>>合規性、安全性、可驗證性、可追溯性。
• 應用巡檢、應用監控等。

傳統金融機構能通過DevOps帶來什麼收益？

什麼是DevOps？

雖然提到 DevOps，大家第一個想到的就是 CI/CD pipeline，但是 pipeline 并不是DevOps 的全部，甚至業界也幾乎看不到單個産品去解決 DevOps 中的所有問題。

為什麼？

通過上述傳統金融機構的典型研發流程梳理，就可以看出，這已經涵蓋了應用/産品從需求提出到上線維護過程中的所有動作。這裡涉及到的，不僅是 pipeline 上內建的各種開發工具，包括 jenkins、gitlab、sonar 等，也包括需求管理、測試管理過程中的其他工具，如瀑布/靈活研發模型、TDD/結對程式設計/各種估算方法等等實踐。并非所有的工具、所有的實踐方法都比對任何一個客戶，這中間會有采納、有适配、有優化、也有放棄。甚至同一個組織，在其發展的不同階段，所使用的的流程、方法、工具也會有變化、演進。

是以 DevOps 項目的建設過程，與其說是一套工具鍊的實施和使用，更完整的定義應該是從組織架構、人員角色、流程規範、平台工具等各個層面的改進與提升。對應的，要想通過一期/一年的項目建設，就建立起組織級較完備的 DevOps 體系，其實是不現實的。

DevOps落地是否一定要綁定靈活研發？

通過上一小節的探讨，其實我們已經知道，在 DevOps 實踐的産品/項目研發階段，我們可以應用到靈活的一些方法和工具，比如 Scrum、TDD。那是否就意味着 DevOps 落地一定要綁定靈活呢？

在我們實際落地的過程中，确實并非所有客戶、所有的産品/項目都是完全采用 Scrum或者是其他靈活方法去完成開發過程的。特别是對于中小型金融機構，瀑布流的項目數量可能會遠遠大于靈活流的項目，這都是在 DevOps 落地時需要去考慮的問題。

我們來用 Azure 上關于 DevOps 與靈活的對比與關系的一段描述來體會一下：

DevOps 的表現形式：

• 持續內建/ Continuous Integration：（代碼）內建、編譯、測試；
• 持續部署/ Continuous Deployment：（制品+配置+資料）部署到環境（非專指生産環境）；
• 持續傳遞/ Continuous Delivery：（系統=原有線上内容+新上線制品/配置/資料）在生産環境傳遞，實作業務價值、産生回報、持續改進。

根據以上的分析，在 DevOps 的語境中，靈活是其中的一種開發方法，DevOps 與靈活的關系，既非綁定，亦非互斥，而是相輔相成。

是以以綁定靈活這件事出發來說，在落地 DevOps 的時候，需要充分考慮客戶的現狀，這個現狀，包括現有的組織架構、人員分工、流程規範、各種工具應用情況，甚至外包團隊的管理方式等因素。DevOps 的建設，也不是上一套系統就可以全部完成的工作。

DevOps的價值收益

DevOps 的核心目标，其實就是研發能效、研發品質、更快更好地把軟體釋出上線，就是所謂的盡快傳遞業務價值。“ 盡快傳遞業務價值 ”這一目标，無論是靈活、DevOps、精益等等概念、體系、實踐方法中都是一緻的。

而這些價值，是如何在傳統金融機構中所展現的呢？

數字化發展、有序推進創新、穩妥發展金融科技，已經明确列入十四五規劃，銀行業、證券業等傳統金融機構的數字化轉型，已經形成共識并展開探索。

在這個探索的過程中，科技的地位正逐漸産生變化，由原來的純粹技術點支撐，逐漸開始與業務側産生更多的互動與融合，如近年來國有六大行和股份制紛紛成立的金融科技子公司、金融雲子公司；而很多銀行客戶也在考慮、籌備、成立的數字銀行部，其實都是在探索這條道路；而在券商領域，不僅僅是頭部券商，包括很多肩部、腰部的券商機構，更是在科技研發上有着非常多的投入，并且逐年還在明顯提升。

而随着監管、市場、需求、技術的變化，金融業軟體系統的技術、組織的複雜度、響應速度和自身品質要求也在日益提升。是以，在這個過程中，科技需要釋放更多的能量，去快速、有效、合規，并且高品質地完成軟體應用系統的設計研發、傳遞運維，是闆上釘釘的剛需。

DevOps 作為軟體工程領域目前大家公認相對更好的一種工作方式和 IT 組織文化，在流程标準方面，具備相當的彈性；在實踐方法上，融合大量的靈活實踐；在工具集合上，具備豐富的開源/商業生态。

作為傳統金融機構的科技部門或團隊，談 “ 科技引領 ” 可能并不适合，但科技對業務響應的速度，業務營運中業務團隊對科技團隊更多的依賴和融合、局部業務快速投入使用擷取回報再繼續改進的場景，一定會越來越多。

而 DevOps，可以是一把鑰匙，幫助科技部門甚至業務部門去不斷地探索和發展。是以當我們掌握了 DevOps 這種工具、方法和文化時，對于科技部門來說，一定是有百利而無一害的。

02 傳統金融機構落地DevOps的困難與挑戰

自上而下，還是自下而上

自上而下更好，還是自下而上更好，這是所有項目都會面臨的一個問題。然而根據我們的經驗，對 DevOps 來說，大多數情況下都是自上而下去做的話成功率和效果更高。

為什麼呢？

大家請思考一下，我們落地任何一件事情的套路，是不是都是：什麼組織、什麼角色和人員，在何種環境條件中，在何種規範架構下，采用一種什麼方法和工具，去完成一項工作，以達成某個目标。我們可以把這個過程稱為一個場景。

而 DevOps 的場景是什麼？請回顧下以上關于典型研發流程和 DevOps 要解決的問題相關章節。我們實際上是需要通過多個部門、團隊之間的持續協作，在一定周期内去完成某個需求或者應用的研發和傳遞。這裡邊大量的人員，他們的文化背景不同、組織歸屬不同、核心KPI不同、甚至個人訴求也有很大差異。

是以完整的 DevOps 落地，一定是一個跨部門、跨角色、跨流程的工作。這一切的順利開展，都離不開高層上司的關注、支援、推動與協調。

建設牽頭部門應該選誰

最典型的中小型金融機構科技部組織架構：開發、運維，可能還有資料；更複雜的可能還會有異地研發中心、重要系統群（對應業務版塊）單獨成立的二級部門；還有些機構可能直接是需求、架構、開發、測試、生産幾個二級部門。

我們接觸的客戶，在最初去了解 DevOps 的時候，以開發、運維部門發起的更為普遍，少數也有是測試部門發起的。

相同的點在于，不管哪個部門發起，其實中長期目标都不是解決二級部門或者某個個體業務系統的研發傳遞過程，而是組織級的，這說明大家都充分認可 DevOps 對于科技組織的價值，并了解 DevOps 是一個跨部門、跨角色的一個長鍊條活動。

不同點在于，如果是開發部門發起，項目的定位會更偏向開發側，比如需求管理、流水線工具鍊支撐、單系統多版本并行開發部署等需求點；如果是運維部門發起，項目的重點可能就會更偏向自動化部署，包括我們看到有些項目，名字叫做 DevOps，實際上隻是在做應用自動化部署這件事；再有比如測試部門發起，可能也是 DevOps 項目，但他們會更關注測試相關的生命周期環節，包括自動化測試的工具等等這些内容。

認識自身的組織與文化

每個企業群組織有着自身的文化與制度，而文化與制度的關系，文化是上限，制度是底線。有企業文化、企業文化在行動中的組織，與企業文化在牆上和官方網站上的公司，在戰略落地過程中是完全不一樣的。我們不可能靠流程制度解決所有問題，因為一切事務都在不停變化，而做事情的始終是人，也不是一成不變的機器。

DevOps 由于涉及到不同部門的協作，以及一些所謂 “ 最佳實踐 ” 的引入，會帶來一些具體工作方法、工具、習慣規約的變化等等，必然會與舊秩序有很多不同的點。很多時候未必是颠覆，但是确實在架構和細節上可能會産生變化。是以如何适配、原有的抛棄哪些、保留哪些，新的采納哪些、放棄哪些，都需要反複的磨合。

如果分析 DevOps 導入沒有達到預期效果的原因的話，就會發現這裡面有一些與文化有關。比如說：組織沒有能力改變文化，以及對變革的抵觸。當發現新的實踐方法與現有的組織文化、上司者管理風格、個人績效産生摩擦，建構跨部門團隊受阻，沖突就顯現了。

如何保持組織靈活的持續性與延續性？

花了 1 年時間，上了 DevOps 平台，導入了兩個業務系統的軟體工程。有了這些，組織就靈活了？

組織是由人組成的，必然會有流動。

當不停的有人進入、有人離開、有人調崗，我們所沉澱下來的 DevOps 相關經驗是否還是适配目前的組織？我們組織中不同團隊對于某一領域實踐的認知是否仍然保持一緻？我們的團隊是否還了解我們為什麼會對某一具體實踐做調整優化？是否還知其然也知其是以然？顧問離場 3 年後，我們如何做到工作模式的與時俱進？

是以組織級靈活性的持續性、延續性以及文化的傳承，實際上不僅僅不是一蹴而就的，還應該是持續糾偏矯正的。

具體的操作上，比如可以間隔性（如兩三年）就重新開機一次組織級的靈活教育訓練、組織内部不同靈活項目小組之間的定期、不定期互通交流、組織上對于過程改進除了鼓勵之外要給出實際的工作時間（8小時以内的時間）用于改進（認可改進的價值），甚至将改進放入績效體系。

03 中小金融機構DevOps落地路徑思路

DevOps/靈活轉型整體視圖

可選的一些切入點

項目協同

需求管理、工作排程，是研發管理中最核心的場景之一，同時涉及到線上工具和線下實踐，是常見的切入點之一。

CI流水線

CI 流水線可以幫助開發團隊完成自動化的代碼內建，并可以導入自動日常建構、代碼品質掃描、自動化測試、代碼分支管理政策固話等線上線下的工具與實踐，也是很好的切入點。

測試管理

相對于項目協同和 CI 流水線，選擇以測試切入的可能會更少一些。這更多是測試部門、品質管理部門會關注的切入領域。但對于傳統金融機構來說，測試可能更多是階段性的工作，很難貫通整個價值傳遞的過程，由測試部門發起的 DevOps 項目，需求上往往會更容易往自動化測試、類測試管理平台的方向上走。

注意事項

立項：務必擷取高層上司的支援與推動；

目标：分階段建設，明确年度目标，不宜貪大求全；

組織：結合建設目标和現狀，明确牽頭部門，關注跨部門協同的難點；

落地：規則限制，可先研讨、線下驗證，再線上限制、逐漸調整，且不宜初期就設定過于細緻的規約；

文化：切勿重系統、輕文化，一定要關注人文關懷，重視組織文化建設，保障一個相對溫和的實踐環境。

完整的 DevOps 體系建設，不僅僅是新工具、新規則，更是新文化，而且在文化變革打頭陣的情況下，很可能取得更好、更持久的成果，讓組織具備自我糾偏的能力。

04 博雲金融行業DevOps落地實踐

博雲自主研發的 BeyondDevOps 平台是提供從“需求->開發->測試->釋出->運維->營運”端到端的開發營運一體化平台解決方案，覆寫項目管理、研發管理、測試管理和運作管理的協同服務和研發工具支撐，将線下 IT 生産過程轉變為線上高度自動化、可視化的 IT 生産線，提升産品研發效率，快速響應業務需求，保障工作品質，并通過度量分析、風險預判，持續提升 IT 營運能力。