[[412171]]

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

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

一、背景介紹

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

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

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

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

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

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

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

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

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

二、核心問(wèn)題&解決方案

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

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

1. 背景

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

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

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

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

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

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

2. 實(shí)現(xiàn)

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

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

(1) 核心執(zhí)行

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

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

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

(2) 執(zhí)行策略

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

• 獨(dú)立線程定期分析運(yùn)行情況，生成運(yùn)行模式；

• 運(yùn)行模式更新和使用采用0-1buf減少讀取&寫入的競(jìng)爭(zhēng)；

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

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

1. 背景

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

2. 實(shí)現(xiàn)

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

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

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

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

2.2 準(zhǔn)入&測(cè)試階段--該階段主要解決測(cè)試效率問(wèn)題

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

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

• 性能diff測(cè)試產(chǎn)出報(bào)告包括上百個(gè)指標(biāo)項(xiàng)，如何分析，如何判斷是因?yàn)橄到y(tǒng)原因引起的波動(dòng)，還是代碼變更引起的上漲，降低分析成本呢？

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

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

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

2.2.1 測(cè)試輸入：智能case生成

1. 背景

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

2. 實(shí)現(xiàn)

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

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

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

1. 背景

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

2. 實(shí)現(xiàn)

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

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

2.2.3 測(cè)試分析：性能白盒分析

1. 背景

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

• 性能測(cè)試報(bào)告包括上百個(gè)指標(biāo)項(xiàng)，要如何分析呢？

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

• 模塊級(jí)耗時(shí)指標(biāo)異常，如何判斷是因?yàn)橄到y(tǒng)原因引起的波動(dòng)，還是代碼變更引起的上漲，降低分析成本呢？

2. 實(shí)現(xiàn)

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

△ 圖表 9：性能測(cè)試白盒分析-長(zhǎng)尾攔截

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

△ 圖表 10：性能測(cè)試白盒分析-波動(dòng)消除

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

1. 背景

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

2. 實(shí)現(xiàn)

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

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

1. 背景

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

2. 實(shí)現(xiàn)

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

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

三、總結(jié)&效 果

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

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

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

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

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