本文整理自QCon北京《何之真 - B站的存量修復(fù)和增量攔截》通過AI音視頻總結(jié)工具Ai好記視頻轉(zhuǎn)文字轉(zhuǎn)錄整理以下為精煉整理后的會議筆記內(nèi)容。講到技術(shù)債務(wù)治理很多團隊的第一反應(yīng)是搞專項治理短期把告警曲線降下來過一陣子又反彈回去然后再來一次專項。B站工程技術(shù)團隊的這篇分享提出了一個不同的思路存量修復(fù)和增量攔截雙軌并進加上AI深度參與構(gòu)建一套可持續(xù)、自動化的技術(shù)債務(wù)治理體系。整場內(nèi)容對在中大型互聯(lián)網(wǎng)公司做工程效能、開發(fā)者工具、代碼治理的人都很有參考價值。痛點為什么技術(shù)債務(wù)治理這么難B站除了視頻業(yè)務(wù)還包括直播、社區(qū)、生態(tài)、游戲、漫畫、大會員、商業(yè)等語言也很豐富主力是 Java、Go、C移動端還有 Kotlin、Swift、鴻蒙等代碼倉庫量級大且持續(xù)增長。單以用戶技助中心為例整體代碼量六七千萬行平均每人十幾萬行每季度新增數(shù)百萬行而主站研發(fā)只有五六百人的規(guī)模。傳統(tǒng)治理有幾個繞不開的問題專項治理不治本是臨時性、階段性的動作無法常態(tài)化還會打斷正常開發(fā)節(jié)奏人必須做優(yōu)先級取舍。問題引入是持續(xù)過程正常迭代、重構(gòu)、bugfix 都會引入新問題引入速度往往超過修復(fù)速度債務(wù)越來越多。人工修復(fù)周期長從定位、復(fù)現(xiàn)、理解、嘗試修復(fù)、驗證編譯、單測、lint甚至部署測試環(huán)境到 app owner review 和合入每一步都靠人每步都可能因優(yōu)先級卡住。核心矛盾在于修復(fù)是單點、離散的行為而問題引入是持續(xù)不斷的。所以作者認為要做好治理需要四個能力穩(wěn)定的修復(fù)產(chǎn)能不依賴人工排期可信的驗證鏈路風(fēng)險分層機制有人負責兜底確認問題并處理AI 在治理中的價值極大提高修復(fù)產(chǎn)能人工一個一個修AI 可以批量自動化還包含驗證步驟。拓展增量攔截在 MR 階段的增量攔截里發(fā)現(xiàn)更多問題避免它們變成歷史債務(wù)。知識沉淀修復(fù)獲得的經(jīng)驗轉(zhuǎn)成 prompt 或 skill 及對應(yīng)評測級用于持續(xù)優(yōu)化。降低修復(fù)門檻原來人要理解規(guī)則再改代碼現(xiàn)在 AI 能根據(jù)自然語言描述直接修人只需看修復(fù)對不對。雙軌治理總體架構(gòu)與核心原則存量修復(fù)解決如何清空歷史債務(wù)增量攔截解決如何避免新問題合入主干成為新債務(wù)。兩條軌道互相依賴存量修復(fù)的產(chǎn)出也是一個 MR必須通過增量攔截再驗證增量攔截發(fā)現(xiàn)的新問題又能作為存量修復(fù)的輸入擴大范圍存量端 AI 負責執(zhí)行修復(fù)驗證交其他工具和角色增量端 AI 擴展發(fā)現(xiàn)問題的范圍并持續(xù)提高準確率四條核心原則雙軌并進存量修復(fù)和增量攔截必須同時進行風(fēng)險分層減少人工介入但保持可控職責明確規(guī)則負責發(fā)現(xiàn)和驗證AI 負責修復(fù)owner 兜底決策回流優(yōu)化成功失敗結(jié)果都回流優(yōu)化規(guī)則、prompt 和策略存量修復(fù)約束下的批量自動化修復(fù)背景團隊 2024 年做了全公司工程能力建設(shè)為幾乎所有應(yīng)用都增加了增量攔截環(huán)節(jié)配置了包含編譯、單測、lint靜態(tài)代碼掃描的流水線要求不能有新增 bug有的團隊還要求不能新增異位或漏洞甚至配置接口測試流水線發(fā)現(xiàn)接口不兼容影響。流程存量修復(fù)流程從 sonar 掃描開始每個 MR 合并后流水線自動掃描相關(guān)應(yīng)用拿到最新問題數(shù)。達到修復(fù)閾值后觸發(fā)自動修復(fù)流水線AI 在約束下工作只在自定義 linter 工具和 prompt 指定的問題類型內(nèi)修復(fù)不在全量問題上自由發(fā)揮只在指定文件范圍內(nèi)修改修復(fù)結(jié)果必須通過同一 linter 工具驗證生成的 MR 必須通過增量攔截流水線再次檢驗最后由 app owner review 決策合入為什么是半自動化早期試點時對所有有問題的應(yīng)用每天全量跑修復(fù)但研發(fā)正處于緊急新功能迭代沒時間 review加上主干頻繁合入導(dǎo)致 MR 一直沖突、最后不得不用 MR。后來改成先收集掃描得到的問題數(shù)據(jù)做報表按應(yīng)用等級、部門、問題嚴重程度同步給應(yīng)用負責人再根據(jù)應(yīng)用重要程度和問題嚴重程度商定修復(fù)閾值達到閾值才批量觸發(fā)修復(fù)流水線owner 也更有動力去 review 合入。效果數(shù)據(jù)用戶技助中心代碼異位從第一季度最高 1 萬 4 千多降到接近平緩的 1 千 1 百多疊加上其他業(yè)務(wù)整體一個季度下降約 90%bug 數(shù)因為工程能力建設(shè)加增量攔截長期維持在個位數(shù)增量攔截在主干之外攔下新問題AI 是對原有 CI 流程的補充增強。MR 的增量攔截流水線必跑編譯、單測、lint部分開啟 AI 能力的倉庫還會跑 AI 相關(guān)的流水線比如 AI CodeReview、單元測試補充、接口測試補充。所有流水線跑完后匯總結(jié)果參考配置判斷哪些弱軟性失敗不阻塞合入綜合得到 MR 是否 ready 合入的狀態(tài)。研發(fā)能看到問題描述和修復(fù)建議對 AI 部分的問題可據(jù)建議修復(fù)其他常規(guī)編譯問題自行處理或暫緩。最終 owner 再做一次 review 決定合入。AI CodeReview對傳統(tǒng) lint 的補充而非替代傳統(tǒng) lint 的局限要把經(jīng)驗固化成規(guī)則由工具執(zhí)行確定性極強只能發(fā)現(xiàn)能形式化表達的問題基于單行或局部模式匹配AI CodeReview 的優(yōu)勢可以用自然語言描述審查意圖能理解代碼上下文、函數(shù)模塊調(diào)用鏈甚至變更意圖從而發(fā)現(xiàn)難以規(guī)則化的邏輯和規(guī)范問題具備需求視角能對照需求、接口約束、預(yù)期行為判斷實現(xiàn)有沒有偏差可構(gòu)建數(shù)據(jù)閉環(huán)審查結(jié)果人工反饋、誤報分析、問題歸因回流去迭代提示詞、更新規(guī)則提升識別能力和準確度分層處理很關(guān)鍵對代碼本身的審查是高置信度結(jié)論作為阻塞合入的門檻有問題必須修復(fù)對需求實現(xiàn)的理解和評估是低置信度結(jié)論只作為提示不阻塞供研發(fā)參考目前 AI CodeReview 只對一部分倉庫開啟開啟范圍內(nèi)準確率在 85% 以上。AI 補充單元測試圍繞 MR 變更函數(shù)流程從 MR diff 獲取變更函數(shù)用代碼圖譜加靜態(tài)分析梳理這些函數(shù)的下游依賴先去遠端存儲找現(xiàn)成單測執(zhí)行并看覆蓋率超過閾值就結(jié)束否則生成新測試生成時在 prompt 里提供整條函數(shù)鏈路信息AI 生成的測試文件可能編譯不過會有修復(fù)編譯循環(huán)把編譯報錯、堆棧喂給 AI 修之后做兩輪分析第一輪用變更函數(shù)及下游依賴信息對失敗 case 歸因把非代碼問題環(huán)境、框架的失敗去掉但不簡單丟棄而是人工收集處理第二輪給 AI 完整代碼庫梳理上下游依賴去除無效 case比如針對防御性編程的失敗用例最終保留 AI 認為有效并經(jīng)部分人工確認的用例保存云端復(fù)用當前狀態(tài)上線不到一個月增量覆蓋率約 85%正確率還沒到門檻AI 標注有效 28 條、人工標注完成 22 條里 12 條有效、準確率 54.5%暫時不把它作為合入門檻等正確率提到 80% 到 90% 再考慮AI 補充接口測試覆蓋率驅(qū)動的迭代閉環(huán)整體設(shè)計整體是兩層循環(huán)。外層循環(huán)生成測試用例內(nèi)層循環(huán)修復(fù)測試用例執(zhí)行中的問題。設(shè)計原則盡可能覆蓋未覆蓋的鏈路一輪只生成一個測試用例避免批量生成互相干擾內(nèi)層也一次只修一條問題批量修容易出現(xiàn)級聯(lián)問題、排查困難執(zhí)行過程基于 mock 回放工具發(fā)現(xiàn)下依賴缺失或 mock 內(nèi)容不對就修對時間戳、隨機值這類高波動內(nèi)容通過策略忽略最后一輪數(shù)據(jù)鏈路復(fù)盤比較接口實際響應(yīng)和預(yù)期是否一致不一致時讓 AI 根據(jù)應(yīng)用日志做完整歸因復(fù)盤輸出交人工確認當前狀態(tài)目前是內(nèi)部試點效果波動較大好的應(yīng)用兩三輪就能到 60% 覆蓋率。總結(jié)與展望核心觀點技術(shù)債務(wù)治理本質(zhì)是持續(xù)運行的系統(tǒng)不能靠一兩次專項完成存量修復(fù)和增量攔截必須同時做驗證要優(yōu)先AI 或人工修復(fù)都先通過驗證再人工 review 合入當前局限存量修復(fù)主要覆蓋少部分低風(fēng)險類型的規(guī)則補充單測和接口測試都還處于小規(guī)模試點未來方向MR 合入最終還是由 owner 決定后續(xù)可以嘗試更精細的分層機制讓某類問題自動修復(fù)持續(xù)優(yōu)化成本總體落地思路是先證明局部成立再平臺化擴張以上內(nèi)容由 Ai好記 轉(zhuǎn)錄整理。Ai好記是一款支持音視頻轉(zhuǎn)圖文筆記的AI知識庫工具支持B站、小紅書、抖音、小宇宙等平臺鏈接及本地音視頻文件視頻轉(zhuǎn)文字后自動生成精華速覽、思維導(dǎo)圖和結(jié)構(gòu)化圖文筆記幫助你把幾小時的視頻內(nèi)容變成可搜索、可復(fù)習(xí)的圖文筆記。