云計算產(chǎn)品大多都會與云原生發(fā)生關(guān)聯(lián)，云原生正在重塑整個軟件的生命周期。但到底什么是云原生？云原生帶來的最大技術(shù)創(chuàng)新和未來機會是什么？圍繞云原生，是否可以構(gòu)建出一套云上的開發(fā)&運維體系，打造新一代研發(fā)平臺，實現(xiàn)研發(fā)效率的最大化？

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

一 團隊效能的影響因素

1 團隊效能的影響因素

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

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

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

2 軟件服務(wù)架構(gòu)對研發(fā)效能的影響

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

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

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

經(jīng)過這三種產(chǎn)品架構(gòu)、技術(shù)架構(gòu)、組織架構(gòu)的分析，相信大家可以理解團隊不斷演進過程中面臨的效能困局。

3 技術(shù)演化帶來的效能變化

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

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

4 企業(yè)研發(fā)效能的制約因素

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

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

三管齊下后就可以有效驅(qū)動這個環(huán)進入正反饋，團隊效率更高，技能提升更快，協(xié)同更加順暢，業(yè)務(wù)發(fā)展好了又可以投入更多的人力成本。

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

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

二 效能工具體系的建設(shè)思路

1 三種典型的研發(fā)團隊

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

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

2 分層建設(shè)效能體系匹配復(fù)雜協(xié)同場景

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

在基礎(chǔ)底座中應(yīng)該關(guān)注產(chǎn)研核心資產(chǎn)的數(shù)據(jù)沉淀，確保整個體系的數(shù)據(jù)一致性，通常會提取研發(fā)體系中核心對象進行下沉，比如團隊、項目、應(yīng)用、代碼、制品等。

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

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

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

目前云效正是按照這個分層思路在建設(shè)研發(fā)工具體系，希望可以將更多開發(fā)者納入到這個體系中來，一同構(gòu)建這個復(fù)雜的生態(tài)系統(tǒng)。

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

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

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

另外兩個是團隊協(xié)同流程和工具，推薦大家深入學(xué)習(xí)效能提升方法、團隊管理方法，并且結(jié)合團隊現(xiàn)狀，個性化到系統(tǒng)中，甚至創(chuàng)新出更適合業(yè)務(wù)特點的工具，逐步釋放團隊生產(chǎn)力潛能。

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

4 進一步的效能提升建議

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

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

三 效能方法體系的演進

1 從強調(diào)工具流程走向強調(diào)價值交付

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

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

2 實現(xiàn)端到端可見的業(yè)務(wù)價值

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

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

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

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

3 ALPD—新一代的精益產(chǎn)品開發(fā)方法

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

這個圖藍色部分是本文關(guān)注的重點。其中分為三個部分，全鏈路數(shù)字化的精益協(xié)作，解決業(yè)務(wù)和產(chǎn)品技術(shù)協(xié)作問題。第二部分是領(lǐng)域驅(qū)動為核心的技術(shù)實踐，解決日益復(fù)雜的架構(gòu)問題。第三部分是云原生的工程實踐，用這套工程實踐去進一步釋放云原生對每一個業(yè)務(wù)開發(fā)者的紅利。

4 全鏈路的精益協(xié)作

首先全鏈路的精益協(xié)作。之所以稱為全鏈路是在這個方法中將業(yè)務(wù)、產(chǎn)品、技術(shù)等多種角色全部納入。最關(guān)鍵的是分層理念，分為業(yè)務(wù)、產(chǎn)品和技術(shù)三部分。分別對應(yīng)業(yè)務(wù)和目標(biāo)管理、需求和產(chǎn)品管理和團隊交付視圖。

在這個模型下，配合一系列高效率在線化工具，讓盡可能多的工作在線完成，數(shù)據(jù)以價值流為核心串聯(lián)和透明化，最終達成精益協(xié)作的目標(biāo)。

5 領(lǐng)域為核心的技術(shù)實踐

再來看領(lǐng)域為核心的技術(shù)實踐。這里分為三個部分，分析、架構(gòu)以及對應(yīng)的實現(xiàn)。分別為業(yè)務(wù)引領(lǐng)的領(lǐng)域建模、領(lǐng)域驅(qū)動的微服務(wù)架構(gòu)、以及契約導(dǎo)向的軟件實現(xiàn)。

領(lǐng)域模型的設(shè)計是產(chǎn)品以及架構(gòu)設(shè)計的核心，良好的設(shè)計可以輕松地解決技術(shù)團隊的變更、測試、交付耦合問題，提升系統(tǒng)可測性和可運維性，并且通過一些防腐設(shè)計，降低技術(shù)債務(wù)對整個系統(tǒng)的影響。

6 云原生的工程實踐

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

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

作者 | 神秀

原文鏈接：http://click.aliyun.com/m/1000288975/

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。