與時俱進「風險系統保障質量之路」非同尋常

京東雲開發者 發表於 2022-11-29

作者:梁鼕鼕

風險系統複雜且又龐大,質量如何保障需要我們付出一點一滴的努力來澆灌系統之花

一、大促備戰,求有序,求穩定:

大促是每年例行高考,把人和系統的各項能力激發,衡量系統健壯,容錯性;凌晨3點的身影就像一束光,奪目耀眼;今年的大促與往年不同,倡導綠色,節能減排,降本增效,把各種資源做到利用最大化,產生更大的價值,讓大促備戰產生了一絲溫度

1)壓測備戰時間表(統籌整體,從4.21-6.23我們把劇本編制到細枝末節,是一條生命線)

2)伺服器擴容縮容計劃(節能減排,把資源利用合理化,讓價值體現最佳)

3)系統最佳化清單(風險策略的不斷增加、迭代,對系統是實時的挑戰,透過不斷最佳化系統,讓系統輕鬆應對大促)

3)壓測目標與評估(精準預估流量,透過流量複製形式生成相關壓測資料,保證資料的還原程度,壓測輪次減少,壓測質量不減,反而增強)

4)壓測介面清單表(計劃壓測介面,壓測輪次,分層分次,僅僅有條)

5)大促備戰準則與規範(備戰規範是我們的方向標,準繩,像大海中的指南針指引方向不能偏航)

6)備戰注意事項(把常規事項羅列清晰,把事情做到最佳)

7)監控與看板(系統風險的兜底方案,我們監控的有力保障,最短的時間發現、定位、解決問題)

8)備戰待辦事項清單(把大促工作相關待辦項羅列清晰,有條不紊的進行展開)

9)備戰會議室與運營(因為疫情,我們把戰場分成線上,線下相結合,提前做好準備工作,打一場勝仗)

二、預警監控,求全面,求精準:

預警監控是質量的最後一道關卡,同時也是質量的兜底方案,我們格外重視建設這塊的能力。

預警全面性:預警分為業務預警、系統預警、資源預警三大類,業務預警在三層最上端,也是對業務結果的檢驗檢測,經過我們長期對業務資料分析,對預警的閾值不斷調優,對預警的等級分層等,業務預警的覆蓋度不斷顯著提升;整體配置預警1000+,業務預警的覆蓋度穩步提升,同比去年提升56%左右,整體覆蓋了核心場景。

1)梳理業務結果資料(對業務細化,業務熟悉度更高)

2)接入風險洞察系統(透過資料來源接入到實時風險洞察實時計算平臺)

3)配置資料集(透過sql配置不同的資料加工邏輯)

4)設定相關告警閾值(透過線上資料分析,得出精準的閾值結論)

5)手機相關接受人,預警等級,預警方式,預警資訊等(把相關的干係人,預警的等級方式統一配置齊全)

6)測試預警觸達(驗證預警的有效性)

7)預警啟用(啟用後,正式運營告警)

8)透過設定預警機器人相關核心預警項,增強預警的監督與及時性(透過機器人運營,把應用負責人跟預警強關聯起來,力保發現的線上問題,在最短的時間內通知到干係人,處理以及監督解決)

預警的精準度:提升預警的精準度,是為了及時發現以及精準定位線上問題 以及 降低預警運營成本最有效的方案;透過我們一年多來研究業務預警,把風險系統的業務預警拆分成多層,透過四分演算法等機制已經形成了一套標準化、統一化、流程化的預警運營的方案,至今事故級別預警精準度達到100%,準事故級別預警達到99.6%左右,高危級別預警在76%左右。

1)事故級別預警(精準度缺失無法容忍block級別)

2)準事故級別預警(精準度容忍略微缺失,精準度至少在99%以上)

3)高危級別預警(高危級別預警類比系統精細化預警,容忍精準度缺失,講究覆蓋度與精準度的平衡,精準度要求在80%以上)

3)高危級別預警(精細化運營類的告警,容忍有精準度缺失,80%以上)

三、自動化覆蓋度,求效率,求變化

在不變中求變,在變化中不變;交付的質量與交付的效率本身是一件衝突的事,可以把衝突的事做成不衝突,要客服種種的困難,不達目的不放棄的精神

移動端篇:裝置指紋是風險側技術能力建設的重要工具以及手段,裝置指紋會以SDK或者JS的方式嵌入到業務的app或者頁面裡,獲取相關的風險資訊,達成風險識別的能力;裝置指紋的自動化涉及到兩個方面:

1)裝置指紋的穩定性:透過調研線上崩潰的區域,容易發生崩潰orANR的部分多數是來自於資料介面的互動導致崩潰,前期透過對業務的呼叫鏈路梳理,把相關崩潰風險的區域,做成了UI自動化,透過指令碼控制手機,執行相關的業務邏輯操作,透過迴圈次數 以及 執行時間控制重複操作來模擬操作,校驗是否會出現崩潰等異常情況;這塊我們已經透過封裝開源的工具,把執行指令碼,採集相關logcat相關的崩潰或ANR資訊列印到測試報告內,透過發郵件的方式,最終收集相關的報告結果,大大提升了測試的效率的同時提升了裝置指紋的穩定性;

2)裝置指紋的自動化:裝置指紋自動化採用UI模擬方式進行自動化,自動化有主控master透過分發的形式,把測試任務下達給每一臺裝置,最終形成分散式的執行自動化的效果,大大提升了自動化的執行效率,同時也提升了裝置指紋的裝置相容性;

3)介面測試篇:風險系統偏底層服務居多,決策業務的是否有風險之本。在風險側展開介面自動化是為了更好的支撐業務,同時也是為了保障質量。為了響應公司的號召,為了達成支援業務最大化,今年開始陸續把自建的平臺關閉,關停了一些ROI低的工作,把相關的業務自動化測試用例,陸續有條不紊的遷移到更佳優秀的介面測試平臺上,把自研開發平臺的人力加到業務支撐,介面的自動化今年覆蓋度從年初的18%到年中的40%左右,實現了主流程鏈路的覆蓋,業務使用率達到32%左右,從行雲裡的資料來看,上半年無論是從測試交付的週期還是吞吐量都有較大的改善,真正的做到了自動化賦能業務,業務交付顯著增長的結果;

4)精準評估需求影響範圍:需求評審、以及測試用例的評審是拉齊研發,測試,產品對需求認知的一場不錯的會議,所以今年P0P1級別需求都要求強制用例評審,評審用例的同時,把大家的資訊拉通,達成一致;今年,在需求評審會里,增加了一個環節,就是透過我們自研的針對增量程式碼的(本次需求)鏈路分析,以及影響的方法範圍,產出一份血緣關係圖,在需求評審的同時,可以精準的圈定影響的範圍,讓影響範圍更加量化,可度量;

5)度量測試質量:作為質量負責人,更關心的是如何管理好質量,那麼質量團隊每個人測試質量的好與壞,或許也是需要度量,可把控;今年推進測試程式碼覆蓋率的執行,透過位元組碼的方式,在測試人員執行用例的同時,可以精準的定位出來,測試用例覆蓋程式碼的行數,來評估測試是否都覆蓋全面,事後知道可度量,可追溯;

6)策略測試自動化:策略測試是風險側獨有的一種測試場景,策略是分析師長期積累的結晶,精華,是風險人的智慧,策略質量的好與壞是對系統有牽絆的。今年透過與策略效能組共建測試平臺,達成了從策略包測試,自動生成案例,再到策略包介面的流量複製,透過線上天然的流量驗證策略配置的準確性,已經形成了一套方法論並落地,今年會加大推廣力度實現策略測試一體化,平臺化,智慧化;

7)混沌工程:混沌工程為大促而生,今年618非同尋常,主戰場為線上線下相結合,在各種的不確定性中我們尋求系統的更加的穩定,健壯。今年引入了混沌工程,把一些核心依賴介面的超時,快取異常,DB當機,伺服器資源各種異常模擬復現,預知了系統風險,大促穩中求穩,不斷求新;

8)UI自動化測試篇:UI自動化歷經數年,UI自動化已經相對穩定,但業務的日新月異,對前端的不斷變更,對UI自動化運營是個不小的難題。綜合看,風險測的UI自動化達成的主要是不頻繁修改的,主流程的,達成覆蓋度100%。非核心場景的,經常變更的,由手工執行,做好UI的用力分層,分類至關重要;

四、質量卡點與風險識別,求全面,求質量

設定質量卡點,是質量體系的線上化的一種方式,說的直白點就是把風險側質量體系相關的規範準則,透過線上化的形式,設定卡點或者實時預警,透過卡點或及時觸達來規避流程、操作風險等

質量卡點是我們重中之重,組之大器,紅線,底線,不可逾越。今年我們最佳化了多處準則規範,為了增強大家的質量意識,形成有效的規範規則,有效的保障質量。

1)上線監控:無論是Jone、jdos、JCI上線都需要走嚴格的審批上線,杜絕順風車,AB異常審批,不經過測試等等上線審批異常行為,透過把JDOS審批流資訊接入風險洞察系統,配置了相關的實時監控,把異常行為監控一覽無餘,杜絕踩踏質量紅線

2) 效率監控:測試交付的效率,交付的吞吐量是度量測試效率的重要指標之一,需要實時的發現問題,解決問題,做到每一個需求,每個人資料透明化,今年也是把效能交付週期配置了相關預警,當交付週期長時,相關的預警會觸達效能小組的相關人,告知效率風險,有人對應跟進分析,給出結果;

3)缺陷與用例監控:測試用例,缺陷都是測試人員的產出物,透過監控分析這些資料,對以後識別系統好與壞,以及測試人員執行的情況最有利的支撐。

4)核心系統上線評審:核心系統上線評審是對系統上線的敬畏,今年核心系統上線,我們都會組織架構師、負責人等相關干係人一起評審業務,程式碼,以及影響範圍;增加一道上線評審,規避質量風險發生;

5)測試用例強制評審:需求評審、以及測試用例的評審是拉齊研發,測試,產品對需求認知的一場不錯的會議,所以今年P0P1級別需求都要求強制用例評審;

6)配置相關風險:配置變更、遷移變更、規則修改、策略變更等等,配置類的釋出是最容易忽視的區域,也是今年要納入測試的範疇的點,配置要經過測試並透過審批流程後方可上線;

7)排期風險:資源投入、倒排期、外部依賴、缺陷處理時間等等,都需要我們關注,要保證專案需求進度無風險,按時交付,力保業務;

8)安全合規風險:資料洩露、洩露使用者資訊、誘導使用者、敏感資料等等都是風險合規的重中之重,需要我們在測試業務的過程中識別出來這種風險,提出風險,規避風險;

9)客戶自損類風險:風險策略攔截、企業授信放款、AB系統銜接、規則漏洞等等都會產生相關的風險,在系統層面把控風險尤為重要

10)系統風險:系統上線風險、系統不穩定、效能不達標、依賴介面異常等等,在功能測試後,要全面評估系統的影響面影響 的種類,提前做好預發預案;

還有未考慮到的方面,歡迎大家補充交流