簡介：?云計算產品大多都會與云原生發生關聯，云原生正在重塑整個軟件的生命周期。但到底什么是云原生？云原生帶來的最大技術創新和未來機會是什么？圍繞云原生，是否可以構建出一套云上的開發&運維體系，打造新一代研發平臺，實現研發效率的最大化？

作者 | 神秀
來源 | 阿里技術公眾號

云計算產品大多都會與云原生發生關聯，云原生正在重塑整個軟件的生命周期。但到底什么是云原生？云原生帶來的最大技術創新和未來機會是什么？圍繞云原生，是否可以構建出一套云上的開發&運維體系，打造新一代研發平臺，實現研發效率的最大化？

我們邀請了阿里云云效研發平臺負責人神秀，分享團隊關于高效研發運維體系構建的流程和方法論。文章包括三個部分：首先從問題出發，分析在團隊業務逐步壯大的過程中可能會遇到的問題，以及這些問題對團隊效能的影響。然后結合問題看下什么樣的效能體系能夠滿足團隊效能提升的訴求。最后介紹阿里云云效團隊對效能提升方法的一些總結。

一 團隊效能的影響因素

1 團隊效能的影響因素

首先探討下企業人員規模增長對效能的影響。剛開始公司初創期，十幾二十人組成全功能團隊，此時團隊分工邊界并不明確，大家在一個非常敏捷的狀態下工作，互相會進行一些補位，比如技術去做一些產品的事情，開發去做測試和運維。這種情況下團隊協作起來基本上沒有太多溝通損耗。往往瓶頸在個人能力上。此時初創團隊為了更快的完成業務需求，在效能工具選擇上更關注單點效率，比如好用的流水線工具、測試工具等等，上手門檻是第一考慮的因素。

當團隊逐步擴張，人員分工開始專業化，多職能協同的問題開始凸顯出來。如何合作，權責如何分配，大家之間的協作流程是怎樣的，是團隊非常關心的問題。此時團隊并不太會因為個人能力而決定產品的成敗，如何提升中位能力是關鍵問題。此時在效能工具的選擇上會更偏向于有一定解決方案的產品，比如分支管理模式，測試環境管理模式，DevOps如何落地等等。這些工具的使用可以很大程度去提升團隊之間透明度，提升溝通效率。比如分支管理模式的選擇，解決開發與測試團隊溝通的問題，DevOps模式更是將絕大部分運維工作交給開發獨立完成，從而通過減少溝通來提升效率。

隨著團隊業務進一步擴大，開始出現有明顯業務邊界的產品，此時在溝通協作成本會被進一步放大，大家更加重視目標、共識和結果。當然可以以戰役模式去承載目標、共識和結果，是非常好的一種匯聚人力資源，topdown的提升執行效率的手段。從另一面也要意識到，戰役并不能解決所有邊邊角角的跨產品、跨團隊協同問題，如何在日常狀態下去解決這種兵力分配、業務技術拉通的問題才是關鍵。

2 軟件服務架構對研發效能的影響

接下來看另一個問題，就是服務架構對研發效能的影響。服務架構其實和組織架構有很強的關聯關系，比如在扁平化架構下，團隊各自獨立互相關聯性不強，有很高的自給率，這里的自給率是指獨立完成某個需求的能力。

在網狀架構下組織形式往往是一體式的，由同一個部門老大帶領，團隊之間緊密配合，我中有你，你中有我。在這個階段架構復雜度高，缺乏抽象。但是因為業務流程相對簡單，做起需求來各團隊點對點溝通也不是太大問題，決策鏈路短，共識快。從另一方面看，技術債務也在累積，當業務之間耦合到一定程度的時候就會出現維護債務的人力投入開始大過新需求人力投入。中臺架構是解決此問題的一個路徑。

到中臺模式下，各種業務模塊開始被抽象出來，隨之技術側也需要組建技術中臺，將原來各自團隊持有的工具開始收斂，流程開始統一。不過隨著前臺和中臺出現分工后，各自發展路線獨立設計，此時就會出現部門墻、前臺業務自給率低、達成優先級、交付時間等共識很困難的問題。

經過這三種產品架構、技術架構、組織架構的分析，相信大家可以理解團隊不斷演進過程中面臨的效能困局。

3 技術演化帶來的效能變化

說完了協作問題，再來看技術的演化是如何影響研發效能的。先粗略的看看過去幾年的幾個技術變化。在2008年開始業界提出了微服務、持續交付、DevOps等等一系列的概念，延續至今。與此同時阿里巴巴也對電商核心系統進行了服務化改造，后來又發現服務多了，管理出現了難題，只有DevOps可以消除瓶頸，釋放生產力。這幾件事其實內部是有一定邏輯的，也就是業務驅動技術變革，技術促進架構變革，架構又推動研發模式變革。

再看最近幾年日益興盛的k8s生態，大致相同，新技術的應用，造就了很多新的架構模式比如serverless，小程序等，這些新的架構給原有的研發模式也帶來了巨大挑戰，比如在Function as Services模式下如何管理代碼分支和環境，測試工具和方法會不會發生變化，測試團隊的職責會不會發生變化等等。當然，大家可以再設想下，當未來服務數量進一步爆炸，架構復雜度進一步提升，這種復雜度超過人的掌控時，會出現什么樣的變化，我們需要使用怎樣的工具去解決那個時候的效能問題。

4 企業研發效能的制約因素

結合上面從人員、架構、技術三方面的分析，在進一步提取中間的關鍵因素，會形成這樣的一個環。這三個關鍵因素就是成本、人、和人與人之間的協同損耗。成本是不可能無限放大的，所以是這個環里面的最關鍵約束。另外因為人的能力參差不齊，那么就無法創造出完美的架構和完美的組織設置，這里面就會出現大量的協同消耗。剛才也提到了，技術債務是會累積的，協同消耗往往會隨著時間不斷放大，消耗更多的人力，在固定的成本約束下會導致更少的業務人力投入。這個環就會出現負反饋，也就是越來越差。所以才有了探討研發效能這個問題的必要性。

通常會采用技術去武裝人，提升個人能力上限，這是筆者認為的重要破局點。接下來需要適應當前團隊組織和架構現狀的協同流程，去降低損耗。需要注意的是這往往只能帶來改進，在固有架構和組織模式不變的情況下很難根本上改變局面。最后可以使用一些工具去讓我們的工作更有效率，以前手工做的現在自動化去做，可以騰出更多時間去聚焦業務價值輸出。

三管齊下后就可以有效驅動這個環進入正反饋，團隊效率更高，技能提升更快，協同更加順暢，業務發展好了又可以投入更多的人力成本。

在阿里自身的實踐中發現，就是在在不斷地改變這些要素，遇到瓶頸投入改進，走出負反饋，進入高速發展，然后又遇到瓶頸。

那么這些問題如何系統化的被提升或者解決，就需要一套適合的效能工具體系。

二 效能工具體系的建設思路

1 三種典型的研發團隊

在我們的實踐中會可以歸納出以下三種典型的研發團隊。

• 第一種是前后臺的應用開發，電商、SaaS等都是典型的形態。這種業務形態在工程側比較容易標準化，工具比較完善，尤其是云原生技術的發展，讓業務的關注點更加向上轉移，底層技術越來越云化，越來越黑盒。
• 第二種是底層基礎軟件研發，業務特點是用戶交互簡單，但技術深度和復雜性較大。這種軟件往往是有狀態服務，并且對硬件基礎設施有強依賴，以至于在運維側就較難標準化。另外在開發側也存在技術棧復雜，多人在一個模塊集中研發的情況，較難像前后臺應用那樣通過服務拆分進行解耦加快迭代，同時也衍生出比如分支管理、二進制版本管理等新問題。這種開發態和運維態的差異性導致了工具體系的差異。
• 第三種是線下交付型的大型軟件研發，以混合云、行業軟件為代表的。因為系統耦合復雜，疊加客戶專有環境因素，對多團隊協同能力和交付運維系統能力要求很高。相對于第一種前后臺應用開發，對版本管理、集成升級、遠程運維能力特別關注。

2 分層建設效能體系匹配復雜協同場景

因此，面對不同的研發場景，不同的側重點，需要對效能體系進行分層和抽象。在這里可以把整個體系分為4個層次，從下到上是基礎底座、工具層、協同層、場景化。

在基礎底座中應該關注產研核心資產的數據沉淀，確保整個體系的數據一致性，通常會提取研發體系中核心對象進行下沉，比如團隊、項目、應用、代碼、制品等。

之上是最關鍵的工具層，工具定義為解決單點問題的自動化手段。其中開放性和被集成性應該是工具最重要的能力。比如常說的api first就是這個道理。

再往上是協同層，這一層產品聚焦于解決人和人之間的信息傳遞問題，以及將這種協同流程進行線上化、標準化。通過對不同領域協同關系的抽象，并且串聯單點工具，最終讓使用者們可以在線完成一個完整的工作。

通用性、可配置性和體驗有時候是矛盾的，因此還需要場景化層的產品去解決各自領域的精細化用戶體驗問題。可以看到最近幾年業界的趨勢就是如此，通用的研發平臺在不斷成熟和做深，而場景化研發平臺不斷產生，通過集成下層工具能力，快速覆蓋細分研發場景。

目前云效正是按照這個分層思路在建設研發工具體系，希望可以將更多開發者納入到這個體系中來，一同構建這個復雜的生態系統。

3 每個團隊定制自己的效能方案

公司除了提供標準化的研發流程體系以外，每個團隊都應該有自己的效能方案來滿足自己團隊的文化和習慣。在這里可以有這兩三個層面可以去提供定制。

一個是團隊工作臺，這是團隊的知識沉淀場所和協同空間。里面提供多種視圖來瀏覽工作狀態以及待辦事項、進度等。還會為leader提供一些列管理工具。

另外兩個是團隊協同流程和工具，推薦大家深入學習效能提升方法、團隊管理方法，并且結合團隊現狀，個性化到系統中，甚至創新出更適合業務特點的工具，逐步釋放團隊生產力潛能。

通過統一平臺可以守住團隊效能的下限，但是效能上限需要團隊自身的努力來突破。

4 進一步的效能提升建議

基于以上分析，筆者提出以下三個建議：

• 第一個是團隊需要著眼于從目標、業務、產品、研發全流程進行效能提升。舉個例子，一個問題：測試團隊如果成為交付瓶頸，是不是完全是測試團隊的責任？很顯然，這里面可能是需求側用戶鏈路分析不全面，或者開發團隊交付質量差，更或者是架構設計不合理導致可測性不強等等，這些都會加重測試團隊負擔，讓測試團隊成為瓶頸。因此團隊負責人需要端到端的去思考，掌握方法并具備宏觀視野，而不是頭痛醫頭腳痛醫腳。
• 第二點是團隊需要為自己的效能負責，是第一責任人。自己最了解自己的團隊，往往采取的措施也是最有效的。
• 第三點是提升團隊產品設計能力、技術能力，減少技術債務，構建內建質量對效能提升非常重要。效能工具體系只能提供最基礎保障，要讓團隊效能更健康，需要從最基礎的軟件工程細節入手，逐步改善，在這方面沒有銀彈。

三 效能方法體系的演進

1 從強調工具流程走向強調價值交付

當團隊分工開始細化以后，從組織角度更加專業化，資源效率更高，但是從業務價值交付的角度來看，周期非常長，而且中間還伴隨著各種等待。

因此可以得出這樣一個結論就是局部效率，并不代表可以高效的交付業務需求。局部效率有很多工具和手段去提升，這是一個相對收斂的問題，甚至可以通過加班去彌補效率的不足，但是高效的交付用戶能夠感知到的業務價值并不容易做到，上面這張圖就說明了這一點。同樣也并不代表可以持續的高效交付，因為從本源上沒有辦法保障永遠用全局最優的組織和架構以及流程去對應，甚至沒有機制去發現瓶頸問題。當然也并沒有辦法去回答業務成功問題，因為業務團隊與產研團隊距離過遠，這種部門墻阻斷了產研去思考和理解業務成功與自己產出的關系。

2 實現端到端可見的業務價值

所以筆者認為效能提升首先要做到的就是端到端可見的業務價值。從業務團隊到產研團隊有以下幾個實施路徑。首先是建立以業務價值流為視角的協作鏈路。以往多半是通過項目管理軟件解決產研團隊的協作問題，以一個產品或者團隊為單位組織需求、缺陷、任務等等。在新的體系中需要將業務團隊也納入其中，并且拉通業務價值與產品研發需求、任務之間的關系，從而實現端到端透明可視。

在產研側采納大量自動化工具仍然是基礎工作，除此之外需要將工具產出的數據能夠鏈接到價值流上，并且盡量沉淀到數據平臺。這里可以采用比較簡單的評判方法，比如有多少百分比的工作是在線完成的，是否有統一的數據模型去積累數據。

在前面兩步完成后，仍然要解決對齊業務、產品、技術團隊目標的問題，比如業務訴求的優先級是什么，時間點是什么，其中的各環節瓶頸是什么，并且在過程中實時追蹤。各環節負責人可以感知到異常事件和資源瓶頸，第一時間去著手解決，達到高效的目的。

第三步要做到持續高效，一定要基于前面積累的數據去量化分析，此時數據的魅力得到展現，越多的工作在線，分析會越準確。哪個團隊在積累債務，哪個團隊在積累資產，哪個團隊是阻塞點，是調整架構還是調整組織分工，這種決策會更加有效率。

3 ALPD—新一代的精益產品開發方法

基于以上的分析，再結合了精益思想、云思想、以及架構設計思想等多方面，可以構建出來的一套方法體系。

這個圖藍色部分是本文關注的重點。其中分為三個部分，全鏈路數字化的精益協作，解決業務和產品技術協作問題。第二部分是領域驅動為核心的技術實踐，解決日益復雜的架構問題。第三部分是云原生的工程實踐，用這套工程實踐去進一步釋放云原生對每一個業務開發者的紅利。

4 全鏈路的精益協作

首先全鏈路的精益協作。之所以稱為全鏈路是在這個方法中將業務、產品、技術等多種角色全部納入。最關鍵的是分層理念，分為業務、產品和技術三部分。分別對應業務和目標管理、需求和產品管理和團隊交付視圖。

在這個模型下，配合一系列高效率在線化工具，讓盡可能多的工作在線完成，數據以價值流為核心串聯和透明化，最終達成精益協作的目標。

5 領域為核心的技術實踐

再來看領域為核心的技術實踐。這里分為三個部分，分析、架構以及對應的實現。分別為業務引領的領域建模、領域驅動的微服務架構、以及契約導向的軟件實現。

領域模型的設計是產品以及架構設計的核心，良好的設計可以輕松地解決技術團隊的變更、測試、交付耦合問題，提升系統可測性和可運維性，并且通過一些防腐設計，降低技術債務對整個系統的影響。

6 云原生的工程實踐

最后是云原生工程實踐。這張圖把工程實踐分為了三個部分，最底層是不可變基礎設施，中間是持續交付流水線，最上層是質量守護體系。

重點在中間紅色部分，也就是GitOps Engine，用這個引擎來全面落地所謂的以應用為中心的IaC體系。筆者認為IaC的設計是開發者對云的運維界面和使用方法的重大重構。通過代碼這種最符合開發者習慣的形式，疊加開放更多自定義能力，可以進一步釋放云原生的技術紅利。

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的高效研发运维体系构建的流程和方法论的全部內容，希望文章能夠幫你解決所遇到的問題。

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