[[412171]]

信息流產(chǎn)品為了給大家提供千人千面的內(nèi)容推薦，后端構(gòu)建了一個龐大、復(fù)雜的推薦系統(tǒng)，整個系統(tǒng)包括上百個模塊，上百個策略算法以及模型，并且這個系統(tǒng)以極高速的效率迭代，日均上線近百個需求； 這樣龐大的系 統(tǒng)如何做到這樣高速穩(wěn)定的迭代呢? 這里離不開 PM、RD、QA等各角色共同構(gòu)建的智能交付系統(tǒng) 。

本文主要介紹了百度大規(guī)模信息流推薦系統(tǒng)研發(fā)、交付效能提升的相關(guān)實踐。涵蓋研發(fā)、測試、發(fā)布、上線部署各個階段，通過智能化手段，結(jié)合數(shù)據(jù)和算法，實現(xiàn)效能提升、以及流程智能流轉(zhuǎn)，最終實現(xiàn)全流程的無人值守。

一、背景介紹

信息流產(chǎn)品為了給大家提供千人千面的內(nèi)容推薦，后端構(gòu)建了一套龐大、復(fù)雜的大規(guī)模推薦系統(tǒng)，整個系統(tǒng)包括上百個模塊，上百個策略算法以及模型，并且整個系統(tǒng)以極高速的效率不停迭代相關(guān)的策略以及架構(gòu)，日均上線百次；這樣龐大的系統(tǒng)如何做到這樣高速且穩(wěn)定的迭代呢？這里離不開PM、RD、QA等各角色共同構(gòu)建的智能交付系統(tǒng)。

智能交付系統(tǒng)覆蓋從研發(fā)、測試、發(fā)布到上線的各個環(huán)節(jié)，首先要設(shè)計一套高效運轉(zhuǎn)的交付模式，并針對當(dāng)前交付模式各個環(huán)節(jié)的問題逐個擊破：

△圖表 2：交付模式示意圖

1. 研發(fā)及自測階段： 以微服務(wù)化、業(yè)務(wù)框架&執(zhí)行引擎為開發(fā)者賦能，降低研發(fā)成本，提升研發(fā)效率，并探索以自主測試為驅(qū)動的新研發(fā)模式，通過QA提供的優(yōu)質(zhì)交付服務(wù)、RD自身質(zhì)量意識和代碼可測性的提升，進而實現(xiàn)研發(fā)測試一體化（測試能力左移為研發(fā)提供服務(wù)、可測性改造等；研發(fā)右移提供更多的基礎(chǔ)架構(gòu)能力、質(zhì)量意識提升等）來試點整體效能提升；

2. 測試階段： 將每個測試行為拆分為測試輸入、測試執(zhí)行、測試分析、測試定位4個子環(huán)節(jié)，在建立完備的測試體系之后，通過數(shù)據(jù)和算法，以智能的手段對各個子環(huán)節(jié)賦能，提升整體的測試效率和召回能力，并釋放排查、定位、結(jié)果校驗分析各處的人力；

3. 發(fā)布階段： 從測試評估角度評估需求是否可以發(fā)布上線，滿足上線條件的需求智能流轉(zhuǎn)至上線部署階段，實現(xiàn)流程的無人值守；

4. 上線部署階段： 從編譯優(yōu)化&部署包裁剪、智能監(jiān)控、并發(fā)動態(tài)調(diào)整，服務(wù)重啟優(yōu)化4個方面，聯(lián)合OP、EE、RD共同提升上線效率；

5. 底層： 依賴于強大的中臺能力，包括配置數(shù)據(jù)管理、構(gòu)建中臺、策略中臺等等中臺支撐流水線高效運轉(zhuǎn)。

△ 圖表 3：智能交付系統(tǒng)示意圖

二、核心問題&解決方案

2.1 研發(fā)&自測階段--該階段主要解決研發(fā)效率和自測效率問題

2.1.1 業(yè)務(wù)框架&執(zhí)行引擎構(gòu)建

1. 背景

目前，融合層的眾多策略&業(yè)務(wù)邏輯，都比較分散。主要體現(xiàn)在以下幾個方面：

• 代碼架構(gòu)： 策略邏輯不內(nèi)聚，數(shù)據(jù)依賴分散，缺乏通用性；

• 研發(fā)效率： 開發(fā)一個調(diào)權(quán)功能，需要修改n個文件函數(shù)，并且每個地方的依賴數(shù)據(jù)和使用方式可能不盡相同，在開發(fā)前需要先熟悉各個位置的代碼，開發(fā)過程中很容易漏掉某個地方?jīng)]開發(fā)到，研發(fā)調(diào)試、測試周期被迫延長。

基于上述背景，預(yù)期實現(xiàn)一個算子執(zhí)行框架，其主要目標如下：

• 規(guī)范算子接口和數(shù)據(jù)依賴，提升策略代碼通用性和迭代效率；

• 框架對外接口盡可能簡單，內(nèi)部執(zhí)行實現(xiàn)盡可能輕量。

2. 實現(xiàn)

框架在實現(xiàn)上拆分成了兩部分： 核心執(zhí)行+執(zhí)行策略。 如下圖：

△圖表 4：業(yè)務(wù)框架&執(zhí)行引擎設(shè)計圖

(1) 核心執(zhí)行

主要功能： 根據(jù)給定『執(zhí)行模式』運行算子。核心細節(jié)上包括如下：

• 并發(fā)多路&短路執(zhí)行功能，輸入處理數(shù)據(jù)組織方式支持：流式&隨機訪問容器；

• 算子支持帶狀態(tài)&無狀態(tài)模式，實現(xiàn)算子執(zhí)行的信息采集和反饋。

(2) 執(zhí)行策略

主要功能：根據(jù)核心執(zhí)行采集的信息，生成『執(zhí)行模式』。具體實現(xiàn)邏輯是：采集核心執(zhí)行每個算子的運行信息，輸入執(zhí)行分析策略模塊，生成下一次核心執(zhí)行的執(zhí)行模式，核心細節(jié)包括如下：

• 獨立線程定期分析運行情況，生成運行模式；

• 運行模式更新和使用采用0-1buf減少讀取&寫入的競爭；

• 執(zhí)行分析策略模塊，采用插件化設(shè)計（類似路由iptable），生成運行模式的時候，順序遍歷每一個策略，支持自定義開發(fā)不同的執(zhí)行分析策略模塊。

2.1.2 新研發(fā)模式試點

1. 背景

所謂自主測試就是RD在研發(fā)過程中自行利用優(yōu)質(zhì)的測試相關(guān)服務(wù)進行質(zhì)量保障，再結(jié)合完備有效的自動化能力直接給出可交付結(jié)論的研發(fā)行為； 整體通過建設(shè)極致流水線和測試服務(wù)能力，引入研發(fā)深度參與測試，并結(jié)合智能化測試落地，提升整體交付效能。

2. 實現(xiàn)

• 流程變化： 原有提交代碼后QA根據(jù)本次變更補充相應(yīng)case，以覆蓋變更場景，左移至RD開發(fā)環(huán)節(jié)；

• RD工作： RD在開發(fā)需求、策略代碼的同時，在QA提供的測試服務(wù)能力基礎(chǔ)上，通過配置case或者編寫自定義校驗函數(shù)的完成case書寫工作，整體case編寫成本30min之內(nèi)；

• QA工作： QA通過建設(shè)可配置化模塊接入，配置化case添加的自動化測試框架，提供低成本使用的測試服務(wù)能力，降低RD case書寫成本；并且測試服務(wù)能力覆蓋包括基礎(chǔ)校驗、策略校驗等90+%核心功能點，流水線覆蓋功能、性能、穩(wěn)定性等P0測試場景，以保障此部分的需求無風(fēng)險上線。

△ 圖表 5：新研發(fā)模式試點

2.2 準入&測試階段--該階段主要解決測試效率問題

我們建設(shè)了集成『自動化測試』、『性能測試』、『穩(wěn)定性測試』等各項工程能力的完備流水線作為準入系統(tǒng)。建立了完備的工程能力之后，我們還是遇到了這樣的問題：

• 自動化測試能力更多的是 作 為功能回歸能力，如何能夠快速覆蓋新增功能，提升自主測試呢？

• 性能diff測試產(chǎn)出報告包括上百個指標項，如何分析，如何判斷是因為系統(tǒng)原因引起的波動，還是代碼變更引起的上漲，降低分析成本呢？

• 包含如此多項能力的準入系統(tǒng)，如何能夠更高效運轉(zhuǎn)，提供給RD和QA絲滑般的流水線體驗?zāi)兀?/p>

所以，在智能交付時期，基于前期建設(shè)的完備測試能力的基礎(chǔ)上，以中臺和數(shù)據(jù)支撐，策略算法賦能，為整個準入系統(tǒng)提質(zhì)增效，并通過分析、定位、評估智能化，流程智能流轉(zhuǎn)，釋放投入人力。

△ 圖表 6：智能化無人值守流水線示意圖

2.2.1 測試輸入：智能case生成

1. 背景

自動化測試能力更多的是做為功能回歸能力，如何能夠快速覆蓋新增功能，將部分非自主測試項目功能高質(zhì)高量覆蓋，提升自主測試呢？

2. 實現(xiàn)

通過對增量代碼的白盒分析結(jié)果，結(jié)合業(yè)務(wù)策略，進行測試用例生成，以盡可能覆蓋本次新增功能。

△ 圖表 7：智能case生成方案

2.2.2測試執(zhí)行：智能構(gòu)建

1. 背景

來自靈魂的拷問，是否針對每個需求，準入階段所有的任務(wù)都需要跑一遍，如果只改了日志類函數(shù)等場景，有必要跑那么重的構(gòu)建？答案肯定是不需要的，但是怎么判斷哪些任務(wù)是需要跑，哪些任務(wù)是可以跳過的呢？

2. 實現(xiàn)

基于智能構(gòu)建中臺能力，結(jié)合業(yè)務(wù)特性，以及白盒分析、歷史任務(wù)結(jié)果等特征，以策略智能決策任務(wù)是否需要運行，打破流水線任務(wù)機械重復(fù)執(zhí)行的現(xiàn)狀，讓數(shù)據(jù)和算法策略代替人來對于流水線任務(wù)裁剪進行決策，進而提升流水線運行效能。

△圖表 8：智能構(gòu)建系統(tǒng)

2.2.3 測試分析：性能白盒分析

1. 背景

為了防止速度衰退，性能diff測試已經(jīng)是測試能力必不可少的一環(huán)，工程能力已經(jīng)完備，但是對于性能測試結(jié)果的分析仍然是這其中的耗時耗力的工作：

• 性能測試報告包括上百個指標項，要如何分析呢？

• 系統(tǒng)級長尾耗時波動問題困擾已久，單一階段耗時的99.9分位值很難判斷是否異常，怎么有效的攔截長尾惡化呢？

• 模塊級耗時指標異常，如何判斷是因為系統(tǒng)原因引起的波動，還是代碼變更引起的上漲，降低分析成本呢？

2. 實現(xiàn)

（1）基于dapper的長尾惡化攔截： 基于RD的全局性能分析系統(tǒng)（dapper system），我們已經(jīng)具備了系統(tǒng)性能的可觀測性，將dapper與線下性能測試結(jié)合作為數(shù)據(jù)依據(jù)，再加上業(yè)務(wù)策略算法做決策，我們就具備了長尾惡化攔截的能力。

△ 圖表 9：性能測試白盒分析-長尾攔截

（2）基于白盒代碼分析波動消除： 基于dapper耗時日志分析結(jié)果，結(jié)合函數(shù)調(diào)用鏈分析，預(yù)估耗時影響，以及增量代碼所影響的耗時階段，對異常波動進行消除矯正

△ 圖表 10：性能測試白盒分析-波動消除

2.2.4 無人值守：流程智能流轉(zhuǎn)

1. 背景

前面介紹的主要集中在研發(fā)自測->準入測試各個階段的效率的提升，效率提升之后，流水線還是需要依賴于人力以及經(jīng)驗進行判斷以及流程上的流轉(zhuǎn)，那么這部分的人力，我們是否可以通過數(shù)據(jù)以及算法來代替人來做決策，讓流水線在各個階段之間更加的絲滑的流轉(zhuǎn)呢？

2. 實現(xiàn)

從需求環(huán)節(jié)開始，在每個節(jié)點，通過質(zhì)量度模型&風(fēng)險評估指導(dǎo)流程流轉(zhuǎn)；在階段的起點，挖掘本次變更引入的風(fēng)險，以及風(fēng)險發(fā)生的概率，相應(yīng)的影響，結(jié)合風(fēng)險矩陣進行風(fēng)險的評估，并在各個階段終點，綜合階段的數(shù)據(jù)以及特征，評估風(fēng)險降級等情況，指導(dǎo)是否可以轉(zhuǎn)入下一階段，最終給出需求上線的綜合風(fēng)險，實現(xiàn)流程上的無人值守。

2.3 發(fā)布&上線部署階段--該階段主要提升部署效率

1. 背景

上線部署階段的效率決定了整個產(chǎn)品能夠達到的發(fā)布頻率的上限，可以降低需求待上線的等待耗時，所以2020年Q3 聯(lián)合RD、OP、EE針對上線部署環(huán)節(jié)效率提升做了專項優(yōu)化。

2. 實現(xiàn)

主要從流程規(guī)范、平臺優(yōu)化、工程能力3個維度，部署包裁剪、并發(fā)動態(tài)調(diào)整、重啟耗時優(yōu)化、監(jiān)控能力智能化等幾個方面入手，針對打包、部署、后置檢查、人工檢查各個階段做相應(yīng)的效能優(yōu)化。

△ 圖表 11：上線部署耗時優(yōu)化方案以及效果

三、總結(jié)&效 果

通過研發(fā)業(yè)務(wù)框架&執(zhí)行引擎、研發(fā)測試一體化、智能流水線、流程智能流轉(zhuǎn)，上線效率提升等等一系列的建設(shè)，推薦技術(shù)方向效能明顯提升：50%+的需求實現(xiàn)天級研發(fā)測試交付，且線上質(zhì)量平穩(wěn)，穩(wěn)中有升。

1. 模式創(chuàng)新： 實現(xiàn)研發(fā)測試一體化，RD在研發(fā)過程中利用優(yōu)質(zhì)的測試相關(guān)服務(wù)進行質(zhì)量保障的自主測試模式，自主測試率大幅提升，從而提升需求交付效率；

2. 天級交付&吞吐上升： 交付需求400+/周，其中50%+的需求能夠天級研發(fā)測試交付；

3. 人效提升： 通過流水線穩(wěn)定性提升、自動標注、智能客服等，大大的釋放了QA在流水線運維投入的人力；通過測試評估以及流程智能流轉(zhuǎn)，實現(xiàn)部分項目無需QA投入，無人值守，QA人效得到提升；

4. 質(zhì)量平穩(wěn)： 迭代效率大幅提升的情況下，質(zhì)量保持平穩(wěn)，且穩(wěn)中有升，線上問題數(shù)平穩(wěn)下降。