2020 年 12 月 23 日，阿里巴巴資深技術專家陳鑫（神秀）在“2020 雲原生實戰峯會”的“互聯網 CTO 數創先鋒營”（閉門會議）中爲現場的數十位互聯網公司 CTO 及技術專家分享《數字化時代，如何構建下一代研發協作工具平臺》。（本文整理自神秀的現場分享，爲方便閱讀，內容有刪減）
本次分享主要由四部分組成：
1、企業在成長過程中遇到的研發效能困境；
2、研發管理從信息化走向數字化的路徑，以及背後的邏輯；
3、雲原生和 AI 兩項新技術在研發平臺上的落地；
4、結合阿里巴巴自身案例，分享如何進行研發管理數字化落地。
1 企業成長與研發效能
企業研發效能的制約因素
在“互聯網 CTO 數創先鋒營”（閉門會議）分享中，阿里巴巴資深技術專家陳鑫（神秀）從人員規模增長、軟件服務架構、技術演化三方面系統地分析了企業研發效能的制約因素，並從中提煉出三個關鍵因素：成本、人以及人與人之間的協同損耗，這三個因素構成一個“環”。
（如下圖所示）
陳鑫認爲成本是不可能無限放大的，所以它是這個“環”中最關鍵的約束。而因爲成本原因，企業往往不能僱傭足夠優秀的工程師，甚至需要採用外包團隊去完成業務開發，因此人員的技能不足是常態。又因爲人員的能力參差不齊，甚至無法滿足技術要求的，所以就無法創造出完美的架構和完美的組織設置，這就會出現大量的協同消耗。技術債務是會累積的，協同消耗往往會隨着時間不斷放大，消耗更多的人力，在固定的成本約束下會導致更少的業務人力投入。這個環就會出現負反饋，也就是越來越差。
那麼，如何走出負反饋，進入高速發展呢？通常我們會採用技術去武裝人，提升個人能力上限，這是重要破局點。接下來，需要適應當前團隊組織和架構現狀的協同流程，去降低損耗。需要注意的是這往往只能帶來改進，在固有架構和組織模式不變的情況下很難從根本上改變局面。最後，可以使用一些工具去提升工作效率，以前手工做的，現在自動化去做，就能騰出更多時間去聚焦業務價值輸出。
三管齊下後就可以有效驅動這個環進入正反饋，團隊效率更高，技能提升更快，協同更加順暢，業務發展好了，又可以投入更多的人力成本。
尋找下一階段效能突破的路徑
從本質出發去思考，以上提到的“研發效率”問題可以拆分爲“協作效率”和“單點效率”兩方面的問題。解決“協作效率”問題，我們需要去思考如何找到組織瓶頸，做到有的放矢？組織和架構複雜度發展到一定程度後，就會形成盤根錯節的協作問題。此時改進的重點其實並不是如何解決，而是找到優化的重點方向，並且能下鑽到具體問題進行突破，最後能看到所採取措施的結果。小團隊的問題顯而易見，而大團隊的問題僅靠感性認知判斷，往往無法直達本質。
“單點效率”方面很好理解，其突破核心在於新技術和新工具的應用，如何釋放新技術帶來的效能紅利是技術團隊始終要去做的事情。
結合以上兩個方面，阿里云云效產品的使命就是讓企業能具備研發敏捷和組織敏捷的雙敏能力。做到這一點的路徑就是研發管理數字化轉型。
2 研發管理從信息化到數字化
研發管理的信息化與數字化
先拋出兩個問題：什麼是研發管理數字化，以及研發管理數字化與信息化的區別。
如下圖所示，左邊是目前各企業通常的做法，第一部分項目協作，在這個版塊主要解決的是多工種的信息流轉問題和知識沉澱問題。第二部分是軟件開發，開發測試人員會採用各種各樣的工具去完成手頭的工作，比如編寫、評審、聯調、測試等等。第三部分是交付運維，需要把編寫好的軟件順利的發佈到線上給用戶使用。
當前有很多工具可以完成這些工作，按照這個流程從上到下，逐步推進即可。但這裏面有兩個問題：
這些工具都是人蔘與其中的，人在推進這個流程中起到了關鍵作用，而工具只是優化了人的一部分工作。
我們更關注過程而不關注這些過程所產生的數據對企業的價值。這些信息成爲了一個一個孤島散落在各處。其實在業務領域做數字化轉型時，核心本質問題都大體類似。
陳鑫認爲 打破信息孤島是研發管理數字化的關鍵，具備以下幾個特徵：
首先是面向業務價值的，這是企業做所有研發活動的終極目標。
第二是全局透明化，不管是業務還是產品、技術都可以掌握全局信息，這也是打破信息孤島的直接好處。
第三是加速信息流轉，提升協作效率。
第四是度量驅動，可以全局的看到效率瓶頸並有效去解決，避免頭痛醫頭、腳痛醫腳。
第五是智能加持，這也是數字化後的一大魅力，人工智能技術輔助甚至代替人去工作，可以從根本上提升效率。
從強調工具流程走向強調價值交付
如下圖所示，當研發團隊分工開始細化以後，從組織角度來看，更加專業化，資源效率更高，但是從業務價值交付的角度來看，週期非常長，而且中間還伴隨着各種等待。
因此可以得出一個結論：局部效率高並不代表我們可以高效的交付業務需求。 我們有很多工具和手段去提升局部效率，這是一個相對收斂的問題，甚至可以通過加班去彌補效率的不足。同樣也並不代表可以持續的高效交付，因爲從本源上沒有辦法保障永遠用全局最優的組織和架構以及流程去對應，甚至沒有機制去發現瓶頸問題。
實現端到端可見的業務價值
陳鑫認爲 研發管理數字化首先要做到的就是端到端可見的業務價值。從業務團隊到產研團隊有以下幾個實施路徑。首先是建立以業務價值流爲視角的協作鏈路。以往，我們多半是通過項目管理軟件解決產研團隊的協作問題，以一個產品或者團隊爲單位組織需求、缺陷、任務等等。在新的體系中需要將業務團隊納入其中，並且拉通業務價值與產品研發需求、任務之間的關係，從而實現端到端透明可視。
在產研側採用大量自動化工具仍然是基礎工作，除此之外，需要將工具產出的數據鏈接到價值流上，並且儘量沉澱到數據平臺。這裏可以採用比較簡單的評判方法，比如有多少百分比的工作是在線完成的、是否有統一的數據模型去積累數據。
在前面兩步完成後，仍然要解決對齊業務、產品、技術團隊目標的問題，比如業務訴求的優先級是什麼、時間點是什麼、其中的各環節瓶頸是什麼，並且在過程中實時追蹤。各環節負責人可以感知到異常事件和資源瓶頸，第一時間去着手解決，達到高效的目的。
第三步要做到持續高效，一定要基於前面積累的數據去量化分析，此時數據的魅力得到展現，有越多的工作在線，分析就會越準確。哪個團隊在積累債務，哪個團隊在積累資產，哪個團隊是阻塞點，是調整架構還是調整組織分工，這種決策會更加有效率。
基於價值流理念構建產研數字化體系
如下圖所示，是構建數字化體系的一個大致框架，在工具側可以將從需求到交付的過程劃分爲三段：需求分析階段、代碼開發階段、交付運維階段，這三段分別對應以需求爲中心、以代碼爲中心、以及以變更爲中心的三個工具平臺。
這三個工具平臺會將數據沉澱到統一的數據中臺之上。而對工具的選型原則就是是否可以構建出完整的價值流生命週期。而這些數據的再次應用，比如需求智能排期、代碼智能應用、效能透視等等，會將企業組織管理推進到數字化階段。
數字化落地的路徑和關鍵要素
在企業要落地研發管理數字化，路徑和關鍵要素是什麼？
第一步 以價值流爲核心。拉通研發效能各個階段，打通工具孤島，進行能力和數據的鏈接。
第二步 建立研發鏈路核心數據模型。通常會以產品、需求、代碼、應用、製品爲核心來構建數據模型。完成這一步後，我們會擁有一個研發數據中臺。
第三步 數據驅動。根據價值流各階段，定義度量指標，洞察出真實的價值交付時間和損耗。可以進一步下鑽到各個階段、團隊的細節，對症下藥。
第四步是 智能化應用。以研發數據中臺爲基礎，擴展上層數字化應用，比如代碼智能推薦、智能監控、無人值守發佈、智能測試等能力。充分發揮數據價值，代替人力工作，從根本上提升效率。
研發信息化是解決企業研發效能的基礎，有了紮實的基礎能力和數據以後，數字化纔有可能。
以上內容講述了陳鑫對研發管理數字化的目標、紅利、路徑的理解，接下來會針對單點效率問題，講述雲原生和智能化這兩個新興技術如何在工具體系中落地。
3 雲原生與 AI 在研發平臺中的應用
雲原生對研發效率的本質影響
以雲原生技術帶來的應用變化舉例。如下圖所示，左邊是傳統應用的研發過程，開發者的代碼會深度耦合中間件，需要關注服務發現、分庫分表、消息處理等多方面。往下也同樣需要關注軟件部署在哪，需要多少容量，甚至還需要關注操作系統、存儲等問題。
在雲原生時代則很不一樣，中間件核心能力會下沉到雲基礎設施中，一些常見的限流、降級、鑑權等能力都無需關心，數據庫、運行環境等都是動態伸縮的，常見的運維問題也不需要關心。只需要開發好代碼，通過軟件交付平臺自動化的發佈到雲端就好。軟件開發的複雜度其實不會消失，而是換一種方式存在。雲原生技術下，這種複雜度會下沉到雲基礎設施層，通過雲去屏蔽這種複雜性。在採納雲原生技術以後大家會發現，中小企業也可以輕鬆獲得以往“互聯網大廠”才能擁有的分佈式、高可用、自動化能力。
因此陳鑫認爲 卸載“offload”是效率提升的關鍵。回想下，企業落地 DevOps 的關鍵要素是什麼？絕對不是簡單地把 Ops 的工作交給 Dev，畢竟運維是一個高風險、專業化的工作。要落地 DevOps，首先要有一套自動化工具和標準化流程去卸載常見的 Ops 工作，比如部署、擴縮容、故障排查等。
再進一步思考，從彙編到高級語言，從物理機到虛擬機，從虛擬機到容器化，基礎設施在不斷地進行標準化。因爲標準化後才能夠有足夠的人才投入其中去完善，碎片化市場很難做大。成熟的技術才能夠做到完全黑盒化，才能放心的去採納。因此 只有標準化技術才能卸載技術複雜度，而正是因爲標準化，纔有了數字化可能。在雲原生下，我們擁有業界統一的技術標準，比如中間件標準、容器標準等。擁有了規範的數據，我們就有機會去創造出各種智能工具，去代替人力勞動，從根本上去解決效率問題。
通過 IaC 構建 DevOps 人機新界面
如何讓研發工具釋放雲原生技術紅利？經過過去一年的探索，陳鑫認爲 IaC 是一個非常好的選擇。IaC 全稱是“Infrastructure as Code”，中文是“基礎設施即代碼”，指的是用代碼定義和變更基礎設施。這個概念其實在 2014 年就被提出了，隨後也出現了 GitOps，也就是把代碼放到代碼庫中，使用代碼庫的版本管理能力來完成基礎設施變更控制。
IaC 和 GitOps 的模式對比傳統 DevOps 工具最大的區別是什麼？是 用戶關注切面的變化。傳統模式需要使用多運維繫統、多控制檯、熟悉多種交互方式。使用命令式模式操作基礎設施變更，此時下層工具只提供原子能力，而人去控制原子能力的執行順序，以及觀測、回滾等等。這就像開一個手動擋的車一樣，需要了解如何換擋，轉速控制，以及油離配合。而新模式下，可以通過代碼去統一定義基礎設施，只描述終態。此時有一個高度自動化和智能化的運維繫統，可以幫助我們去安全高效的完成變更。就像在開一個有自動駕駛功能的汽車一樣，只需要告訴他要去哪。
但很遺憾，目前爲止，IaC 模式都只是被少量運維人員用於編排雲資源來使用。而廣大開發者羣體都在老的模式下工作。這項技術的廣泛應用不但需要 DevOps 工具平臺的升級，而且需要一個高度自動化和智能化的運維繫統進行匹配。在過去一年裏，阿里巴巴就在建設這個系統。
基於 GitOps 模式的應用平臺設計
接下來，陳鑫簡要介紹瞭如何將 GitOps 模式落地到 DevOps 工具中。如下圖所示，展示的是雲效新一代應用交付平臺的架構示意圖。
先來解釋下什麼是應用，應用一般包含多個組成部分，比如一個服務進程、一個數據庫、再加一個 Nginx。而且，一個應用可以被部署在多個環境，比如測試、預發、正式環境等。
用過 K8s 的同學應該都知道，本質上 K8s 就是面向終態的 IaC 模式，定義資源都是用一段 YAML 文件來描述。但是 K8s 都是面向資源來設計的，主要服務對象是運維人員，而應用這個概念是爲開發人員設計的。所以需要在 K8s 概念之上擴充出這個工具體系。大家可以關注下 kubevela 這個開源項目，這就是阿里 GitOps 方案的開源實現。
接下來，簡單介紹下這個應用平臺的組成，從上到下，第一層是用戶界面層，開發者可以通過界面 UI，或者 cuelang 一種腳本語言來對應用進行編排，其中 cuelang 模式是顯性的代碼化，而 UI 是幫助用戶生成代碼。
下面是應用的靜態編排，需要描述應用的組成，比如可以是 K8s pod，也可以是函數，或者是虛擬機，或者是多種組合。再下面是環境以及機器組的配置，描述環境資源所在的物理地點。
當我們要執行一次代碼發佈或者擴縮容，甚至是更復雜的運維變更時，用戶會通過 UI 或者代碼對應用描述進行變更，App GitOps Engine 會將變更內容通過 Cloud Provider 進行下發到雲去執行，最終自動化的完成變更操作。
研發管理數字化的願景
“講完雲原生的例子，我們再講下智能化。這是我心中關於研發管理數字化的一個願景。”陳鑫介紹說。
首先，從協作、編碼、測試、交付、應用運維，可以全面使用雲化工具一站式完成。先進的工具加上先進的理念可以幫助企業構建透明高效的組織。 當我們不斷生產和積累知識後，研發數字化的魅力開始展現。
在未來，智能化研發管理助手將成爲承載我們最先進的軟件工程技術和能力的化身，它會承擔兩大職責：
代替人去完成繁瑣的工作，比如缺陷排查、故障發現、持續監控、協助溝通等等。
成爲軟件交付專家，根據每個企業的實際情況，推送最優質的代碼，最合適的編程框架，最適合團隊的流程改進建議等等。
接着，他簡單介紹了阿里巴巴在代碼領域數據智能工具落地的方向，比如在代碼效率、質量、安全方面，阿里云云效分別開發了代碼缺陷預測、敏感信息掃描、智能評審、代碼補全、代碼庫異常行爲監測等產品。
4 阿里巴巴的工程實踐
阿里巴巴面臨的效能問題
前面介紹瞭解決協作效率和單點效率的一些思路，接下來看一下阿里巴巴面臨的效能問題及解決問題的方法。
阿里巴巴面臨的效能問題是什麼呢？我們從業務側和技術側兩方面來看。
從業務側看，阿里爲避免業務團隊重複建設，從而導致數據不統一、業務流程混亂等問題，發明了業務中臺這個概念。業務中臺其實並不完全是通用性邏輯，它是通用邏輯和各個前臺業務定製化邏輯的結合體，因此就產生了一些新問題，比如業務中臺中的通用邏輯和一些前臺業務定製邏輯迭代速度不一致，從而出現部門協同、排期、優先級問題，互相影響效率。有些前臺業務還對應多箇中臺產品，多方協調存在一個巨大的溝通成本。
從技術側看，阿里在服務化架構下發展多年，雖然在高可用方面頂住了歷屆雙 11 的考驗，但也帶來巨大的副作用，比如應用運維工作開始變大，調用鏈路開始變長，而且都是分佈式服務問題，排查難度變大。打個比方，大家在淘寶上買一個商品，這個鏈路會跨越多個 BU，比如淘寶業務、共享業務、支付寶業務等，涉及的團隊一線開發者很難講清楚。不管是完成一個業務需求，還是排查一個問題，都需要大量溝通。現在還面臨 PaaS 層上雲考驗，如何用好衆多的雲產品是個很大的問題。
阿里一直以來希望通過技術和組織的變化，來做一些解耦，讓不同團隊掌握自己的業務發展節奏，分開來跑。但是這種解耦並不能完全消除協作的複雜性，架構的複雜性，而是換了一種方式存在。當我們面對這種業務爆炸、應用爆炸、協作研發成本日益增高的情況時，如何去破局是個非常大的挑戰。
破局路徑上的挑戰
解決問題之前，除了剛纔的定性分析，還需要更多的定量分析來洞察關鍵瓶頸。
如下圖所示，是目前阿里在用的一個研發階段度量模型。先粗略的觀察目標 BU、團隊的效率關鍵節點，然後再下鑽到具體問題，分析是協作還是技術問題，解決什麼具體的場景可以打破瓶頸。如果大家對這裏指標感興趣，可以進一步瞭解。
結合定性、定量和調研分析，可以得出了以下三個關鍵方向：如何解決中臺協作問題、如何解決日益複雜的架構問題、如何進一步釋放雲原生紅利。
面對如此複雜的問題，如果直接去解決單點問題，必然是隻見樹木不見森林。在這裏，給大家介紹阿里最近在解決集團效能問題過程中總結的一套方法 ALPD。
ALPD—新一代的精益產品開發方法
這是阿里云云研發團隊結合了精益思想、雲思想、以及架構設計思想等多方面構建出來的一套方法體系。
這個圖藍色部分是我們今天關注的重點。其中分爲三個部分：全鏈路數字化的精益協作，解決前面講的的中臺協作問題。第二部分是領域驅動爲核心的技術實踐，解決日益複雜的架構問題。第三部分是雲原生的工程實踐，用這套工程實踐去進一步釋放雲原生對每一個業務開發者的紅利。
雲化一站式 DevOps 平臺的發展趨勢
“好方法的落地永遠離不開工具，”陳鑫說：“而我本人的職責就是用工具去承載方法，用工具去鏈接開發者和雲基礎設施，爲企業研發管理數字化發展做一些事情。”
當前，阿里云云效推出了一系列好用的工具，可以幫助企業快速上雲，包括項目管理、知識庫、代碼平臺、自動化流水線、製品管理等等。阿里巴巴集團依靠雲效平臺，完成了從手工到自動化的轉變，從傳統運維模式到 DevOps 的轉變，從虛擬機到容器化的轉變，相信雲效的經驗和產品可以幫助到大家，讓各位不再爲研發效率問題發愁。
5 總結
最後，陳鑫表示：當然，我們現在做的還遠遠不夠，結合我前面對研發數字化路徑分析和方法的總結，在這裏講一下，我對未來趨勢的一些判斷。首先是 ALPD+ 釘釘的雲端協作體系，這是解決持續高效交付業務價值的基礎。其次是基於場景化的雲端編程體系，比如小程序、Serverless 各種新的編程框架日益增多，一招鮮的玩法會逐步被替代。第三是基於 IaC 理念的雲原生研發模式，第四是研發數據中臺，這是從簡單度量指標分析轉變爲數據洞察決策分析的基礎。最後是智能研發的全面落地。
本文爲阿里雲原創內容，未經允許不得轉載。