vivo 互聯網研發效能關鍵技術與實踐
一、互聯網研發挑戰與方案
隨著互聯網業務的快速發展，業務規模和用戶體量在不斷擴張，在如此大的規模和體量下，對研發交付效率及質量也提出了新的要求和挑戰。
（圖中數據統計截止時間為2024.07）
vivo互聯網業務廣泛，體量巨大。伴隨而來的是互聯網項目快速增長，最近5年增長超過了5倍。與此同時，項目的服務數量也出現大規模增長，最近6年從原先少于2500，到快速增長超過8000，服務數量增長超過3.7倍；服務器數量也同時期增長了2.8倍，研發交付和穩定性保障的復雜度成幾何式增長。可以看到隨著項目、服務、機器的大規模增長，研發團隊規模也發生了較大的變化，前后增長超過2.7倍。隨之而來研發協作難度逐步增加，甚至出現效能下滑的傾向。
（圖中數據統計截止時間為2024.07）
隨著研發復雜度增加，互聯網研發流程也變得規范，與此同時，支撐的工具和平臺能力也非常豐富。但是這也帶來了交付復雜度的上升，項目成員往往需要在多個平臺來回切換，非常麻煩！正如圖所示，從需求洞察到需求運營至少需要經歷10個階段、10多個角色的高效協作才能完成，顯然相比以前復雜了許多，也逐步顯示了需求交付效率下降的情況。
項目流程和平臺復雜度增加的同時，在技術層面，研發基礎設施也是幾經變遷，線上線下環境的機器復雜度持續增長，變更與維護難度逐年上升，對變更質量的要求越來越高。
從上圖可以看出，在2017年以前，研發整體線上交付的機器以物理機為主，所有的線上運維都是交由專門的業務運維及DBA角色來執行，開發人員主要參與編碼和測試工作。
但隨著研發規模增長，快速交付、低成本的資源也逐步開始引入像OpenStack這樣虛擬化技術，此時用戶的操作也逐步從原有運維逐步轉向類似CICD這樣自助化運維交付平臺。
并且隨著內外銷業務的發展，越來越多彈性、快速、低成本的云主機也逐步引入，平臺從簡單流程逐步發展成體系化、場景化平臺，用戶的使用成本也逐步攀升。
回顧上面業務規模、研發體量和流程平臺的現狀，以及基礎設施的變遷，vivo互聯網業務面臨相當大研發效能提升的挑戰。
總結來看：
- 研發規模攀升，研發交付復雜度持續上升。
- 研發交付橫跨多個階段，在多個平臺間操作，成本非常高。
- 隨著基礎設施的變遷發展，平臺需要不斷兼容不同資源、不同云廠商、不同用戶場景的訴求，為平臺建設和項目實踐帶來了非常大的挑戰。
回溯過去與當前的困境，結合公司文化行為準則，vivo研發效能團隊堅持以用戶導向深入業務側，從頂層進行設計與規劃，提出“1-2-3”建設框架：通過1個雙環模型、2個標準化、3條研發管線助力研發效能持續提升。
第1層結合“價值探索”與“價值交付” 的持續交付雙環模型。左環確定方向與目標，強調采用“提問”-“錨定”-“共創”-“精煉”的方式來循環驗證；右環則偏重過程交付，快速實現左環目標，并保持業務結果與價值達成。
第2層定義了兩個標準化：需求標準化、研發標準化。需求標準化更加強調需求從提出到需求實驗全鏈路閉環管理，最終實現需求端到端交付；研發標準化更多強調從分支拉出到交付上線的標準化、自動化過程。
第3層為了重點支撐業務、數據、以及模型和算法需求的研發交付，規劃了3條對應的研發管線，將原有煙囪式能力串聯成體系化工具鏈，致力于打造絲滑流暢的開發者體驗。
二、互聯網研發效能關鍵場景技術
根據上述研發效能現狀來看，我們規劃了研發效能的需求標準化、研發標準化。根據2個標準化，我們梳理了3個關鍵場景：需求自動化、標準流水線、測試自動化。
需求標準化：需求自動化作為標準化實現的關鍵，它作為需求整個標準化驅動引擎，推動需求狀態自動流轉。從而實現分支創建和合并、測試環境交付、測試自動化驗證等場景串聯，達到全鏈路需求標準化交付目的。例如：需求拆分任務時按照分支策略自動拉分支，需求轉測時能夠自動合并分支，以及觸發流水線執行測試環境發版，及時更新測試環境版本。
標準流水線：主要流水線內卡片類型有明確的規范，為了減少流水線配置，推進流水線“一人配置、多人共享”，實現流水線并行執行，不受運行時流水線的限制，使得滿足所有目標項目符合持續集成的要求。
測試自動化：作為研發效能質量提升的重要措施，在需求狀態發生流轉時，則自動觸發流水線實現測試環境更新，以及觸發測試用例的執行，主要包含流程管控自動化，以及測試實施自動化兩個方面。
上面需求自動化是為了解決需求端到端過程中自動化串聯，那原先需求自動化是解決什么問題呢？我們接下來看下目前互聯網需求流程端到端流程，不同階段的場景之間自動化率較低，大部分靠手工操作。并且根據該頁下半部分來看，支持研發效能實施操作的平臺較多，圖上所示的基本只是在平臺層面有單一支持，并沒有實現串聯，用戶多平臺操作成本較高。
根據圖上流程顯示多平臺操作成本高，自動化聯動率較低，面對這樣的用戶痛點問題，我們需要根據上述流程示意圖，3個大的階段7個關鍵狀態和3個核心平臺之間動態自動化聯動。
首先，在需求階段，需求從納入迭代時就根據分支策略自動化拉取分支，完成需求設計進入開發階段，當需求狀態從待開發狀態變成已完成開發時，則自動化觸發測試環境流水線運行。
其次，觸發流水線運行后則首先將分支進行合并，并且將合并后的分支執行代碼靜態檢查和代碼評審，通過之后借助全鏈路能力快速拉取多版本測試環境，與此同時也同步觸發測試平臺的測試用例執行，涵蓋功能、性能等接口測試用例。
再次，完成測試環境搭建以及測試用例的執行，生成對應的測試報告。此時流水線將結合測試結果動態生成上線工單，也同步反饋更新需求狀態到待上線狀態。
最后，待上線工單完成相關審批，此時將按照預設策略執行線上部署，完成線上交付，則自動反饋需求狀態更新已上線狀態。到目前為止，我們能夠看到整體的狀態流轉絕大部分以上都自動化完成。
上述我們談到需求自動化的流轉流程，那要實現這樣的自動化流程，我們要如何做到呢？如圖所示我們能夠看到完成整個自動化流轉需要4個部分：事件觸發機、規則匹配引擎、規則執行器、日志記錄器。
首先，在觸發執行之前，我們需要先配置觸發執行規則，例如：“當xx發生時，則執行xx事件”等，并且將規則的執行主體、觸發時機、執行動作關聯。此時，一旦規則的觸發時機達到條件時，則產生觸發事件，加入事件隊列，采用先進先出模式執行。
其次，當事件隊列出列某個觸發事件之后，則將事件傳播到規則匹配引擎，此時通過匹配規則進行模版匹配，一旦匹配通過，則將規則對應的執行主體任務取出，并且觸發action動作，例如：傳遞xx參數并調用指定流水線運行等，最后將執行狀態返回，記錄到日志。
剛剛我們看到的是需求自動化的上下游觸發，要是能夠讓進一步提升研發交付效能，我們此時就需要關注通過流水線實現標準化交付。從圖上我們能夠看到要想實現交付成熟度從1.0提升到2.0，需要提升持續交付的規范化，我們知道單純依靠流程規范來實現流水線按照指定的規范配置和執行，只能通過平臺標準化流水線配置與運行，才能以實現交付流程的標準化和一致性。
為了實現標準化流水線，需要3個部分。
首先，需要定制標準流程，約束所有業務研發團隊統一標準化流程操作；
其次，要考慮多場景觸發，則需要保證流水線可并行運行；
最后，要通過標準檢查來保證流水線能夠按照設定好的規則配置，從而實現標準化交付。
上述我們也提到要實現標準流水線，需要支持流水線在多場景下并行執行，提升流水線的使用和運行效率。談到并行執行，我們類比類與實例的關系，目標是一套流水線配置，可以并行根據參數動態運行不同實例。
那我們來一起看看并行流水線如何實現的，考慮到流水線在運行過程中根據具體配置，固化按照預設分支、環境運行。為此，要想實現并行執行。
關鍵如下：
- 去除排隊限制，讓統一條流水線可以支持運行多個實例；
- 執行過程中隔離資源（機器、環境、任務等），避免環境污染；
- 動態生成不同執行任務，并自動觸發運行；
- 保證任務運行過程中資源隔離，避免運行環境污染；
- 之后要注意運行結束后隔離資源回收是否全面。
上述談到要實現流水線標準化，靠人工檢查效率低下，此處基于標準規則和檢查機制來保證。為此，我們來了解下我們是如何實現標準化規則檢查的，此處核心是將所有配置位運算可解析的格式，通過&和^操作來實現。
正如上圖所示，我們將規則檢查分為兩個關鍵步驟：
- 通過&識別是否一致，主要通過二進制位檢查來識別是否有通過檢查；
- 如果不一致，則通過^和&再次識別具體不一致的位置，從實現快速校驗和識別，將得到的結果到數據庫中比對出不一致的流水線及歸屬服務。
我們從需求自動化到流水線標準化，主要關注效率維度提升，接下來我們看下在質量維度的提升。在測試域我們關注的測試活動實施，主要分為兩塊：流程管控自動化、測試實施自動化。
流程管控自動化，通過打通了研發域、交付域、測試域，完成測試任務的自動流轉，從而實現覆蓋了80%項目的測試活動。
對于測試實施自動化而言，測試實施分為客戶端和服務端兩個維度。
- 對于服務端測試：接口和性能自動化、變更風險可視化是確保服務端高質量測試交付的關鍵，兩者的自動化覆蓋度超過70%的核心項目。
- 對于客戶端測試：通過統一的插件化方案實現各類自動化能力（穩定性、功能、埋點等），并支持實時監控手工測試過程中相關數據，從而保障客戶端測試的整體效果。目前覆蓋超過90%的APK應用。
我們提到接口測試自動化，那我們來一起看下如何實現？接口自動化實現總體分為4個大的步驟，分別是：接口管理、用例轉化、用例執行、輸出報告，其中接口管理考慮場景，又分為接口自動化掃描和流量錄制。
接口錄制階段：接口掃描采用agent組件在java工程測試環境啟動過程中動態采集工程所有的java訪問接口，并且實時將接口數據上報到接口服務平臺。
接口管理階段：除了支持工程掃描，也可以借助自研流量錄制平臺進行錄制，并且將線上錄制好的接口鏈接及參數登記到接口服務平臺。
用例執行階段：通過將接口參數進行解析，動態生成接口測試用例，并針對生成的接口測試用例進行驗證是否有效。
報告輸出階段：通過接口測試用例動態生成，我們后續可以將單個測試用例進行批量組合成套件，可以根據代碼變更動態識別出需要自動化測試的接口用例，通過手工、流水線、定時進行觸發，并且將測試的接口生成測試報告通知給用戶，便于用戶實時關注測試結果。
我們了解了接口的自動化，通過自動化我們可以有效提升測試的質量。但是我們都知道，接口的穩定性除了功能的完整性測試之外，也需要考慮在目標用戶體量下的穩定性和可靠性，我們接下來一起看下關于接口自動化壓測的實現，談到接口性能壓測，那必然離不開接口、性能測試用例，以及壓測需要的環境。我們從整體來看，壓測過程分為兩個部分：線上環境接口錄制、壓測環境流量回放。
- 線上環境接口錄制主要是采用我們公司自研的流量錄制回放平臺月光寶盒（MoonBox），通過moonbox-sdk將線上流量采集并推送到平臺，之后將錄制的流量接口數據存放在ES數據庫中，待壓測平臺IPT需要的時候拉取。
- 用戶在IPT壓測平臺開啟壓測時，平臺根據用戶指定的配置動態形成壓測策略推送到壓測服務，并通過壓測服務轉化為一組組壓測任務下發到壓測集群，考慮到壓測任務體量不同，壓測集群借助容器可以動態伸縮，實現目標體量的完全模擬。通過壓測集群批量、動態非線性實時壓測，與此同時IPT壓測平臺會動態從監控平臺獲取壓測環境監測數據，并且將性能壓測結果進行整合，最終形成目標壓測報告發送給用戶。
三、研發效能項目實踐與效果
我們介紹了在效能平臺建設過程中面臨的挑戰和關鍵技術。當然所有能力的建設都會回歸到助力業務效能提升上面去，在實際的業務中我們是如何實踐這些能力提升研發效能。
在“應用商店”項目中，我們在“需求交付標準化”和“研發過程標準化”的框架下，重點實踐了需求分層管理和自動化驅動，標準流水線和自動化測試，有效地解決了在需求管理和研發流程中的效率問題。
vivo應用商店是vivo官方團隊傾力打造的應用下載及管理平臺，為vivo手機用戶提供海量的應用和游戲，是一款工具產品，也是一款商業化產品，既協助開發者獲客的同時促進合規，也要在幫助用戶獲取應用時做好風險管控。對于上線的需求有著嚴格的評估流程，會經過需求、開發、測試、上線、實驗等各個階段的各類評審與評估。通過對應用商店研發效能成熟度的評估，發現在需求管理、質量保證和持續集成方面還有很大提升的空間，為此我們的實踐重點也是從這里展開。
首先，通過需求的分層管理，將需求拆分成可以在線上進行獨立商業驗證的特性。在評審和設計環節，我們的過程涵蓋了產品、需求、策劃以及埋點，通過持續的評審來保證正在做正確的事情。
其次，在開發層面，將業務特性分端拆分成不同的用戶故事，并進行開發和測試的閉環。整個需求流程的推進，更多的依賴工具來驅動，避免人工導致的錯誤和流程執行的不到位。
比如說：
1）在需求的開始，項目管理工具會自動創建需求群，在策劃評審通過后，流程引擎會通知數據產品和設計進行埋點和UI設計，在所有開發準備工作完成后，自動進行分端拆分用戶故事，并通知項目管理人員組織進行排期。
2）在開發完成后，項目管理工具會協助開發創建驗收單和測試單，并將必要的信息填充在工單中，開發人員所需要做的就是填寫少量的信息，并提交執行。
最后，所有的項目活動，通過項目管理工具流程引擎來驅動，讓開發專注于開發，測試專注于測試，流程的事情交給系統，力求一次性把事情做對。讓項目團隊持續、高效、高質量的進行價值交付，可以看到應用商店2024年上半年我們將需求研發平均交付時長優化至17天。
除了上面的需求流程自動化，我們在研發過程也進行了很多優化探索。我們在整個研發階段打通各個系統之間的交互，詳細如下：
需求階段：我們在項目管理工具VAPD上對需求進行排期，確定好版本號后，通過“分支管理” 功能配合自定義的分支規范，一鍵創建并拉取各個服務的代碼分支。并將各個服務的分支與流水線、工單、代碼評審平臺、發布等系統關聯，后續所有代碼分支相關的活動都可以自動化的處理。
開發階段：我們設計了六條不同規格的流水線，涵蓋了我們研發的各個階段，比如“開發流水線”，會監聽所有人的代碼提交。在代碼發生變動時會自動執行我們的預先定義好的各項任務，包括各類安全檢查，靜態代碼分析及代碼規范檢查等等，將發現的問題實時通過V消息反饋給開發團隊，將盡可能多的檢查工作都放在開發階段，盡早暴露編碼過程中引入的各種風險和問題，實現驗證左移。
測試階段：當我們的開發結束，并通過 測試平臺測試合格，制品晉級成功后，我們開發的產品就可以進行發布上線了，當然這個過程仍然伴隨著各種自動化工具的配合，我們的流水線會推進整個發布過程，自動化點檢平臺會對所有的功能進行回歸、點檢、驗證、灰度，確保發布功能的完善。
上線階段：最后配合埋點、告警、監控、云診斷等手段，將我們的發布過程可視化。
縱觀整個過程來看，參與的角色和平臺非常的多，平臺很多都是獨立或者自動化能力不可達，需要人工傳遞或者手動編輯，我們將各平臺能力打通，真正實現狀態和數據的自動流轉。下方也列出了我們統計到的一系列提效數據，從分支管理到工單自助，從需求建群到任務催辦等等，最終我們在2023年實現開發人力節省超過270人天
我們介紹了更多的我們在開發編碼階段所實踐的內容，接下來看看在測試階段，我們做了哪些提升。
首先，測試過程中最重要的一環是我們要測試什么內容？如何圈定測試的范圍？傳統的方式是我們的測試人員根據需求，配合開發人員的意見來分析可能的業務影響范圍、編寫測試用例，整個過程其實相對主觀，靠的是我們常說的經驗主義，依賴于測試、開發人員的經驗，對業務的理解深度，以及對上下游關聯關系的掌握程度。
其次，這個能力是因人而異的，過程也是偏主觀的，容易造成判斷錯誤或者遺漏。所以我們要做的第一個提升就是通過工具來更客觀的分析業務的影響范圍，依據的就是代碼的差異性分析和上下游調用鏈圖譜，即通過編碼前后代碼的變化來確定哪些服務、接口受到了影響，同時結合調用鏈圖譜檢索可能被這些服務或接口影響到的上下游。這樣在一定程度是彌補了不同測試水平人員在主觀經驗上的差距，以及各個業務上下文帶來的影響。
再次，通過不同規格的流水線驅動，執行綁定的各類不同任務實現持續測試以及驗證左移，這些任務包括了各類自動化的檢查與驗證，功能的、性能的以及人工介入的。
最后，通過我們的測試準出門禁，確保制品的輸出質量，并將測試過程中產生的數據資產沉淀到后續的準出報告中。最終，在這些流水線和自動化工具的支撐下，我們整個研發階段的測試活動滲透率提升了 156%，測試執行效率提升了 35%，版本發布的成功率也提升到了 97.27%。
四、研發效能未來規劃
從上述的近幾年在研發效能關鍵場景和項目上落地情況有了一定了解，那未來計劃如何繼續推進研發效能呢？接下來我們就一起聊聊研發效能未來的規劃。
談到研發效能每個公司都面臨不一樣的情況，vivo互聯網研發效能也經歷前前后后4個大的階段，從早期的開源工具化時代到場景化業務賦能時代。
工具化時代：早2018年及以前，vivo互聯網還是主要以解決當時研發管理過程中遇到的問題和痛點展開，不斷提升研發過程白屏化、自動化，盡可能借助開源和商業化工具JIRA、SVN、Gitlab、Jenkins、SaltStack等來提升研發運維效率。
平臺化時代：隨著平臺種類規模增加，用戶需要基于自己的訴求去“找”平臺和工具，然而平臺也面臨著“找不到”用戶的兩難境遇。
體系化時代：我們也考慮建立體系化平臺，消除用戶與平臺的“隔離”，讓用戶能夠在平臺解決自己的訴求。
場景化時代：與大多數公司的發展一致，平臺經歷多年的發展以后，隨著用戶體量、業務復雜度增加，平臺個性化、定制化訴求逐步導致平臺維護和使用成本進一步增加，讓平臺研發團隊維護成本非常高，也讓用戶的訴求受到了影響。為此，如何從用戶場景出發規劃和實現成為關鍵。
談到這里vivo互聯網研發效能的未來到底是什么？vivo互聯網研發效能團隊結合自身經歷來看，還是要回歸本源。結合行業的先進理論體系，進一步走進業務研發團隊，找到真正的痛點與訴求，幫助業務團隊“做正確的事，把事情做正確”。
我們前面聊到對研發效能新的認知和理解，未來我們將進一步走進業務來提效。我們為此也定義三個北極星指標來牽引我們的目標達成，分別為：代碼前置變更時間1小時內，需求研發交付時長在2周內，需求實現到結果閉環3周內。
根據研發效能新的理解和目標，我們也多次回滾本源，思考我們的最佳路徑，總結來看就5個階段，分別為：
第1階段實現工具全面自動化，消除絕大部分黑屏和手工操作。
第2階段工具實現串聯，能夠結合項目研發流程初步具備自動化流轉。
第3階段實現研發效能信息全面拉通，平臺之間的研效信息能夠在多個平臺間自由的共享，實現多維度、多角度度量識別效能低洼，并且結合研發流程不斷提升項目的研發效能。
第4階段之后，平臺能夠基于平臺度量的能力逐步識別項目內個性化研發場景的短板，并且結合研發效能實踐專家，深入項目內部，真正結合場景自助化、自動化進一步項目研發效能。
第5階段就不僅僅關注項目本身的研效，而是需要回歸需求本身去關注整體價值達成效果。
我們期望通過目標來牽引業務，將OKR、項目、需求等不同層級的要素進行連接。通過可視化看到任務分解、進展、數據效果，以及資源投入和風險，真正意義上做到“一層支撐一層”，層層看得清、管得明。從而實現始終在做正確的事情。除了上面的需求流程自動化，我們在研發過程也進行了很多優化探索。
