本文整理自美團技術沙龍第77期《美團億級流量系統的質量風險防控和穩定性治理實踐》。文章第一部分介紹了軟體系統風險與變更；第二部分介紹了程式碼變更風險視覺化系統的能力建設；第三部分介紹了整個系統在美團內部實踐落地的情況；最後是對未來的規劃和展望。希望對大家能有所幫助或啟發。
1 軟體系統風險與變更
變更是軟體系統進化的推動力，同時也是孕育風險的溫床。如果一個系統沒有了相應的迭代和變更，那這個系統就會逐漸失去了活性和價值。不過，隨著系統進行了變更迭代，軟體風險也會慢慢衍生，而規避變更引發的軟體風險在質量保障領域是一個較大的挑戰。透過對下面典型軟體系統架構圖分析，我們可提煉出3大類變更維度：
- 基礎設施變更：主要包括基礎硬體變更、運營商網路變更、雲服務容器變更、開發語言變更、作業系統變更以及機房叢集的變更，這些基礎設施迭代極大提升了系統底層的服務能力，一旦變更引發系統風險，其影響面通常也比較大。
- 系統外部變更：比如使用者流量突增、使用者需求變化以及相關三方服務及三方元件變更，這些幫助系統不斷衍生出新的迭代能力，同時也增加了系統穩定性風險的發生。
- 系統內部變更：比如技術人員迭代、新功能釋出以及系統整體架構的升級等，這是驅動系統軟體進化的核心變更因子，也是最頻繁的變更風險發生地。
在這裡，我們先列舉了一些比較常見的、因變更風險所引發的典型線上事故：
- 外部變更所引發的線上問題，某地的光纜被挖斷導致整個服務有很大的影響。
- 程式碼變更典型問題，谷歌Gmail系統在釋出新功能時產生的副作用而引發的功能上問題。
- 程式碼變更典型問題，Knight公司在升級一段很老的程式碼時引發的異常邏輯功能發生。
- 配置變更引發的問題，所引發的“薅羊毛”事件。
- 人員操作變更，研發誤操作引發的整個核心資料刪除；
可以看到，在實際的工作中，由變更所引發的風險，對業務的衝擊非常大。結合美團億級流量的到家業務形態看，系統變更引發風險可能性進一步放大，變更風險的“蝴蝶效應”更加凸顯，某個單點問題都有可能給整個到家核心業務帶來極大的影響。
- 第一，從到家業務接入方看，美團內部業務包括外賣、閃購、醫藥等等，外部有眾多的企業客戶。
- 第二，系統參與相關方較多，包括C端使用者、商家、配送騎手及各個平臺。
- 第三，業務基於微服務架構模式，各個業務間呼叫關係複雜，核心鏈路非常長。另外，業務強依賴配置，一旦某個環節發生變更問題，相關方都會受到影響。
所以對研發與測試來說，洞察與規避變更引入的質量風險變得至關重要。
那麼，關於變更風險，質量建設核心做功點在哪裡？我們對歷史線上問題分析發現，系統內部變更引發故障的佔比較高，且變更與程式碼變更有直接或間接關係。因此，我們開始圍繞程式碼變更這個核心變更因子，構建了質量建設的做功點。
隨後，我們思考了兩個關鍵問題：
- 程式碼變更風險是否可被視覺化，提升測試和研發感知能力。
- 圍繞程式碼變更風險，是否能夠構建一套質量保障防禦體系。
透過分析發現，結合下圖的程式碼特徵樹，我們就可以更好地感知程式碼變更的視覺化能力。然後透過各葉子節點，將所有相關特徵很好地識別，並且做對應的質量防禦策略。
2 程式碼變更風險視覺化（后羿）系統建設
傳統測試模式存在兩個典型問題：第一，對於研發開發的程式碼，缺少全面視覺化分析能力；第二，對於程式碼變更所產生的影響範圍有多大，實際上更多地依賴研發人員和QA的經驗。所以，在這樣的傳統測試模式的典型問題情況下，我們希望從3個維度做質量保障建設方案：
- 第一階段是程式碼變更的感知能力，重點解決對於不同的程式碼形態和不同的程式碼工程模式，如何能夠最大範圍地覆蓋到所有的程式碼變更情況；
- 第二階段重點做程式碼特徵刻畫，將所有變更程式碼抽離出不同的特徵，打上作用標籤；
- 第三階段基於前兩個建設能力，構建對應的應用場景生態圈，在不同測試流水線階段，都能夠將程式碼變更風險的刻畫能力嵌入，不斷做質量防禦。
而程式碼變更風險的質量保障建設方案最終的落地形態，是打造一個程式碼視覺化分析系統，在到家內部我們將其命名為后羿系統。顧名思義，我們希望該系統能像“后羿射日”一樣，在質量風險評估和攔截層面能夠做到更加精準，同時提升質量防禦能力。該系統架構主要分為四層：
- 第一層是基礎元件層。
- 第二層是程式碼分析層，重點解決對不同的程式碼形態都能夠做到精準的程式碼變更分析和識別。
- 第三層做特徵刻畫層，核心解決整個程式碼的結構化標註和特徵化標註。
- 第四層負責構建業務應用層，在不同的場景和環節下，將程式碼變更視覺化能力嵌入到這個環節中，構建一個完備的質量風險攔截能力。
除此之外，我們也會引入智慧化手段，賦能整個系統。同時，我們也將核心能力透過開放Open API方式，輸出到其他的質量效率相關的工具平臺上，賦能美團內部的其他工具平臺。
總的來說，對於后羿視覺化系統的關鍵流程，在應用層的透出是透過兩個入口進行感知：一是后羿主站；二是工程交付平臺。我們透過非同步訊息感知分析任務和原始碼下載，獲取對應的變更檔案、變更方法和變更行號；同時再借助位元組碼解析能力，解析對應的呼叫鏈路變更情況，儲存到圖資料庫裡；再對變更程式碼做特徵打標和識別；最後會產生一份視覺化分析報告，直接給到對應的QA使用。
當然，在整個建設過程中，我們也遇到了一些技術層面的挑戰。
第一個挑戰是程式碼分析技術。在系統建設初期，透過AST單分析能力做程式碼分析和識別，但存在Lambda表示式識別問題和Java泛型識別問題，在此基礎上引入了ASM位元組碼分析技術解決了前面的問題，但ASM也會有自己的Java反射特性相關問題無法識別。所以我們希望未來引入動態化程式碼分析技術，來解決反射類問題。
第二個技術難點是海量關係資料儲存問題。在建設之初，透過關係型資料庫做儲存，但隨著系統的廣泛應用，儲存了大量呼叫鏈路拓撲關係資料，但它的查詢效能非常差。所以在此基礎上，我們透過探索引入圖資料庫的儲存方式，解決了在海量資料關係儲存資料的查詢效能。
第三個技術難點是程式碼風險特徵多樣性，像個性化特徵跟我們的業務有強相關性，比如資損特徵、對應的分頁特徵和多執行緒特徵。針對這種風險特徵，我們之前的開發模式是系統開發者和業務QA深度溝通對應的識別策略，但這樣的方式溝通效率和開發週期都比較長。
因此我們做了整體能力改進，透過開發一套元件化開發框架，將整個開發框架開放給各業務線QA，他們可以自己開發定製化開發元件，載入到后羿系統，完成多樣性特徵的快速識別能力。
3 程式碼變更風險視覺化（后羿）系統實踐
接下來，我們重點給大家介紹系統的實踐應用落地情況。如下圖所示，該圖為后羿質量保障應用場景生態全景圖。目前後羿系統整體建設了八個核心應用場景：
- 技術方案層面校準診斷
- 在Code Review階段能力的增強
- 變更影響面評估
- 介面級的用例推薦
- 配置變更風險診斷能力
- 相容性風險診斷能力
- 程式碼特徵風險預警
- 開放Open API能力
首先技術方案缺失項診斷，在專案測試過程中，主要包含以下2個痛點：
- 研發寫技術方案時，標準化程度較低。
- 中間反饋的問題對於技術方案更新時效性較差，但我們發現技術方案對QA來講是一個關鍵性的依賴輸入，從而導致QA在寫測試用例時，往往會遺漏掉一些關鍵性的變更資訊，比如介面定義變更缺失、配置項定義變更缺失、定時任務變更缺失、非同步訊息變更缺失以及DB表欄位變更缺失，這些資訊往往在技術方案裡更新不全面。
基於這樣的情況，后羿系統透過對程式碼的識別，能夠真正拿到在本次程式碼層面上，真正變更了哪些資訊，再拉取對應的技術方案做解析，再做關鍵變更資訊項的Diff，從而生成一份技術方案的缺失項診斷報告給到對應的QA，QA可以根據此報告做對應的診斷項卡點攔截，同時做測試用例的完善補充。
第二個應用場景是增強版的Code Review評審新模式，傳統的Code Review也面臨幾個痛點問題：
- 研發在整個Review過程中更多地聚焦在編碼規範和架構設計合理性上。
- 常態化的Code Review模式基於純文字，它也有幾個痛點：第一是無法針對Review的過程做變更方法的上下游快速跳轉檢視；第二無法做到對變更方法、改動方法的跳轉或呼叫鏈路的業務邏輯呈現。
基於這樣痛點問題，后羿系統打造了基於變更鏈路場景驅動Code Review新模式，核心解決在Code Review階段能夠更早地感知質量風險。其核心做法是后羿系統在Review一個變更檔案時，能夠快速提煉出變更檔案裡對應的變更方法、變更變數以及這些變更方法和變數上都具備哪些風險特徵，從而讓QA和RD快速抓到變更的重點資訊。
在此基礎上，我們也提供了變更方法的上下游快速跳轉能力，基於Review過程中做變更方法的快速跳轉，理解整個業務的上下游關係，同時在跳轉過程中，能夠將跳轉的邏輯點實時繪製成呼叫拓撲圖，感知變更方法之間的業務邏輯關係，更好地從整個鏈路視角評估本次程式碼變更的影響情況，很好地解決在Code Review階段的痛點問題。
第三個應用場景是變更影響範圍評估，目前後羿系統構建了六大變更影響範圍評估能力：
- 程式碼基本屬性，比如變更了哪些方法；
- 能夠支援到HTTP、RPC以及JAR包等不同形態程式碼工程型別；
- 能夠對通用風險特徵做識別，比如事物遞迴相容性問題；
- 可以對定製化風險特徵做識別，比如許可權、演算法特徵；
- 可以支援單服務影響，包括方法呼叫鏈路，介面特徵、訊息特徵、任務特徵等等；
- 跨端服務的影響面評估，比如一個服務內部的呼叫鏈路和在不同的微服務之間的跨端變更點之間的鏈路影響是什麼樣子的，都能夠做到更精準地影響範圍評估能力。
影響面評估示例：
- 一個變更介面被影響到了，那麼它的下游到底是哪些變更方法影響的？我們能夠很直觀地看到這個變更介面下面有哪些新增的和變更方法所影響到的。
- 下游所變更的影響方法之間的鏈路呼叫拓撲關係是什麼樣子？我們能夠透過鏈路拓撲圖，快速繪製出來對於這個介面下面所有變更方法之間的呼叫鏈路。
- 對應的變更方法對於介面中間所有方法的呼叫鏈路詳情，我們也能夠透過這個能力快速做評估和刻畫。
- 對於一個介面下面所有方法的鏈路呼叫關係是什麼樣子？我們也提供了一個全方法鏈路的檢視分析能力。
第四個應用場景是配置變更的風險診斷，在比較複雜的大型業務上，整個系統對配置往往有強依賴關係，比如典型的灰度配置、降級配置以及內部邏輯相關控制配置項，對於整個系統的影響比較大，但往往QA和研發人員對於配置風險的把控實際上比較缺失，認為程式碼可能更多的是質量保障的重點，所以由於配置所導致的線上問題比較多，造成的結果比較嚴重。
基於這樣的核心痛點問題，后羿系統重點從三個層面做了關於配置變更風險的核心能力建設：
- 在配置的變更識別分析層，我們能夠很好地對各種型別配置做精準識別：是新增還是變更。
- 透過後羿影響面評估能力，拿到配置所影響的介面、影響鏈路以及對應影響的非同步訊息和定時任務。
- 有了影響面評估後，我們能夠更好地透過測試，將變更場景做到覆蓋，由此構建了配置變更測試覆蓋度量。因為我們在配置測試過程中對於測試結果的感知能力不強，因此透過基於流量挖掘、流量錄製能力構建了實時感知配置測試的覆蓋情況。在整個流水線層面，透過關鍵配置變更卡點能力更好地防禦配置變更所引發的一些問題。
下圖是我們目前所建設的應用功能頁面：
第五個應用場景是服務端相容性的風險診斷。我們透過對線上問題做彙總分析發現，新老相容性這類典型問題佔比較高，我們嘗試透過後羿系統解決，QA能夠做簡單的相容性問題識別，比如一個介面的入參返回值有明顯的欄位新增或型別變化會明確判斷出來。
但在相容性問題分析上，有一類不太明顯的變化導致了相容性問題，比如入參層面有一些約束條件、由可選欄位變成了必選欄位，這類變化實際上在整個程式碼定義層面很難感知到；另外一類是變更引數是透過內部間接呼叫VO類直接組裝出來的，實際上對於QA也很難感知內部間接VO類變化的相容性風險影響。
所以後羿系統基於這樣的痛點，構建了反射和序列化，從而快速拿到對應的底層變更VO類所導致的對介面影響能力，給出相容性介面預警，QA根據這樣的分析診斷報告，進一步評估對應的相容性和上線順序的合理性安排。
第六個是介面級自動化用例推薦，對於到家的複雜業務，我們沉澱的很多自動化用例怎麼用，是全量回歸還是選擇性篩選，也是比較大的痛點問題。因此後羿系統基於所具備的識別變更方法、分析影響鏈路以及對應的介面能力，打通和到家智慧程式碼覆蓋率平臺所具備的歷史流量覆蓋情況，能夠快速拿到變更介面和方法，再借助一體化平臺，拿到對應的自動化用例，做精準的自動化用例推薦，從而構建了用例推薦整體解決方案。
第七個典型的應用場景是程式碼質量風險特徵預警，我們在質量建設過程中，往往會遇到一類比較特殊的場景需要驗證，比如資損類場景，除了驗證功能外，還需要對資損做個性化風險功能場景驗證、異常場景驗證、特殊分頁邏輯、重試場景驗證，但這些場景在整個程式碼過程中，我們往往很難發現這些特徵風險，從而忘記驗證特殊場景情況。
針對這個問題，后羿系統從兩個方面構建了特徵風險識別功能：一是系統會自己構建通用風險特徵識別策略模型，二是各業務方也會自己打造對應的風險特徵識別策略。
如下圖所示（最下側），是目前已經具備和未來將要建設的特徵識別能力。有了核心識別能力後，我們再將對應的特徵在所要驗證過程中相應上下游的依賴平臺做工具能力整合，對於不同特徵構建出相對應具體測試策略的推薦策略，將這幾個能力打通後構建出一套基於程式碼質量風險特徵的體系化質量保障方案。
第八個應用場景的能力是開放Open API的賦能能力，我們希望將后羿系統分析識別的資訊，透過開放API的方式透露出去，能夠給到對應相關工具平臺使用。目前在到家範圍內已經將整個能力開放給了介面管理平臺、智慧程式碼覆蓋率平臺、全息系統、異常測試平臺、自主工程交付系統以及一體化自動化平臺這六個核心的效能工具建設平臺。
4 未來規劃與展望
結合具體的實踐，以及此前總結的經驗。未來，我們將從四個方向做未來質量保障建設：
- 程式碼分析技術的增強，希望能夠透過動態鏈路分析技術，提升整體的分析準確性。
- 風險特徵識別技術，希望能夠基於大語言模型相應能力對風險特徵的分析和對應測試策略做推薦。
- 進一步豐富應用場景生態圈，探索在不同測試環節、不同測試場景下，將后羿能力做更好的整合，賦能到具體的業務質量建設中。
- 長期來講，希望將系統的核心能力，透過開源共享方式賦能給相關測試領域。
5 Q & A
Q1：單次分析報告耗時是多久？同一個工程程式碼的報告間是獨立的還是有關聯的？
A：目前1-2min可產生分析報告。報告是基於迭代任務維度生成的服務級報告，比如一個專案迭代裡有5個工程程式碼變更，那麼這5個工程程式碼變更關係會作為一個整體分析，體現到報告裡。
Q2：鏈路的拓撲關係是怎麼實現的？
A：鏈路的拓撲關係基於AST技術和ASM技術進行分析，同時，結合線上Mtrace鏈路關係作為補充。
Q3：微服務多模組之間的服務呼叫鏈路可識別出關聯性嗎？如HTTP介面後續呼叫多RPC服務介面?
A：微服務多模組之間的服務呼叫鏈路可識別出關聯性，比如HTTP的下游會呼叫了哪些RPC介面，目前具備可識別能力。
Q4：底層方法的呼叫鏈非常多，這種有推薦策略嗎？DB變更是掃描Mapper嗎？
A：目前對於呼叫鏈路會進行風險特徵打標處理，比如：鏈路包含資損特徵、配置特徵等，透過特徵風險標籤能夠更好的讓使用者感知到鏈路風險等級，為後續測試策略提供關鍵資訊推薦。目前DB變更是透過掃描Mapper進行識別的，基於Mybatis整體DB開發框架做變更掃描。
Q5：關於用例推薦，是推薦單例介面還是會組合成場景介面？
A：目前是推薦單介面用例，比如這個變更介面關聯了10個自動化用例，我們會把這10個自動化用例推薦出來。
Q6：分析一個工程大概會花費多長時間？
A：目前要花費1-2min時間。
Q7：實際應用中，主要收益是什麼？
A：主要收益是基於八大應用場景落地應用，所有應用場景都會給質量與效率帶來價值收益，比如在相容性問題上已成功攔截多起相容性質量問題；在配置變更風險評估上， 已成功攔截多起因配置預設值編碼錯誤、線上線下配置不一致問題。
Q8：這套平臺是否會對線上服務可用性帶來影響？
A：目前這個平臺對於線上服務可用性不會造成影響，針對線上環境進行分析時，核心操作是拉取線上對應的部署JAR包，不會對現實服務造成可用性影響。
Q9：這個系統有護城河嗎？這個系統收益是什麼？對業務有什麼幫助嗎？在業務上有什麼體現嗎？
A：說到“護城河”，變更分析底層技術上主要還是基於AST和ASM通用技術，核心是對各種業務程式碼編寫方式的相容支援、業務場景特徵識別精度等維度上有一定的技術挑戰。
主要收益集中在變更帶來的業務影響範圍的風險評估及對質量風險的有效攔截上，目前已成功攔截多起介面影響範圍評估不準的Bug、配置變更相關Bug、相容性Bug等。
在業務幫助上，一是八大應用場景能夠給整個質量和效率帶來提升；二是可提升對業務理解的效率，比如透過介面下游呼叫鏈路視覺化能力，可很快理解這個業務鏈路關係。
Q10：鏈路拓撲過大，怎麼解決，不同服務使用語言不同，位元組碼技術有啥推薦嗎？
A：鏈路拓撲過大時，可透過鏈路聚合來歸類提升視覺化，針對美團是Java技術棧，重點在突破Java識別能力，其他語言服務分析後續會持續關注與解決。
Q11：可以分析出對上下游服務的影響嗎？
A：是的。
Q12：分析程式碼變更，如何識別有效變更和無效變更？
A：比如變更了一段程式碼，它有可能沒有呼叫方，我們叫做預埋類程式碼。類似這種程式碼在測試過程中很難用業務場景進行驗證，而且未來上線後很可能會引入潛在風險，目前透過鏈路變更分析可有效識別此類預埋程式碼風險。
Q13：系統使用的階段都是什麼？准入階段還是準出階段？
A：目前系統在准入和準出階段都可以使用，沒有做嚴格限制。
Q14：識別出的問題噪音干擾多嗎？
A：從噪音干擾層面講，我們做了很多提升識別率的策略最佳化，比如HTTP/RPC介面識別率目前已達到98%以上，噪音干擾可做到很好的控制。
6 本文作者
桂來，來自美團到家研發平臺。
| 在美團公眾號選單欄對話方塊回覆【2022年貨】、【2021年貨】、【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞，可檢視美團技術團隊歷年技術文章合集。
| 本文系美團技術團隊出品，著作權歸屬美團。歡迎出於分享和交流等非商業目的轉載或使用本文內容，敬請註明“內容轉載自美團技術團隊”。本文未經許可，不得進行商業性轉載或者使用。任何商用行為，請傳送郵件至tech@meituan.com申請授權。