作者 | 神秀
來源 | 阿裡技術公衆号
雲計算産品大多都會與雲原生發生關聯，雲原生正在重塑整個軟體的生命周期。但到底什麼是雲原生？雲原生帶來的最大技術創新和未來機會是什麼？圍繞雲原生，是否可以建構出一套雲上的開發&運維體系，打造新一代研發平台，實作研發效率的最大化？
我們邀請了阿裡雲雲效研發平台負責人神秀，分享團隊關于高效研發運維體系建構的流程和方法論。文章包括三個部分：首先從問題出發，分析在團隊業務逐漸壯大的過程中可能會遇到的問題，以及這些問題對團隊效能的影響。然後結合問題看下什麼樣的效能體系能夠滿足團隊效能提升的訴求。最後介紹阿裡雲雲效團隊對效能提升方法的一些總結。
一 團隊效能的影響因素
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的設計是開發者對雲的運維界面和使用方法的重大重構。通過代碼這種最符合開發者習慣的形式，疊加開放更多自定義能力，可以進一步釋放雲原生的技術紅利。
免費下載下傳電子書
《阿裡巴巴DevOps實踐指南》
《阿裡巴巴DevOps實踐指南》是由阿裡雲雲效團隊20多位專家聯合推出的最新方法總結。指南首次系統地總結了阿裡十年DevOps實踐經驗，核心内容包含：數字化轉型下DevOps的核心目标、阿裡巴巴DevOps實施的4大價值主張和與之比對的技術實踐體系、阿裡巴巴DevOps工具體系大圖、企業DevOps能力成熟度進階模型等。
目前指南免費開放下載下傳，
點選這裡，立即下載下傳吧~