背景

易盾業務主要分內容安全、業務安全和移動安全三部分，內容安全主要給客戶提供反垃圾機器檢測能力，文本、圖片和音視頻。并和人工審核、SAAS審核系統組合成全家桶。業務安全主要是提供認證類的服務，包括驗證碼，號碼日志，信息認證。移動安全是通過加固和其他手段保護客戶的應用，防止被逆向破解。

結算業務是易盾最重要的基礎服務，承擔著易盾的資金管理工作，隨著易盾用戶量的高速增長，結算業務承擔的責任越重，風險也越大。自然而然，對于我們測試同學也提出更高的要求。在我們搭建這套體系前，回歸手段比較傳統，自動化用例維護成本較高，覆蓋不夠全面。也沒有完備的線上監控，缺乏自我發現的能力，有較大的資損風險，并且故障發生到發現的時間很長，導致故障的影響面擴大，用戶的信任度降低。

1.1、結算流程介紹

以反垃圾的結算流程為例：

首先圖片、文本、音頻和視頻等業務服務檢測完成以后會通過各自的storage模塊將檢測量或者審核量發送給kafka，bill-collect模塊收到消息后會根據業務配置以及套餐信息計算并寫入到redis，隨后統計任務會將上個時間段存在redis的數據持久化入庫，最終由多個結算任務對前一天持久化的數據進行結算。任何一個環節出問題都會影響最終的結算結果。

1.2、痛點分析

結算的痛點一直是團隊心病，內部溝通過后將痛點總結為以下三點：

下面我們會針對這三個問題各個擊破。

測試工具改進

2.1、痛點分析

上面大致介紹了一下結算的流程，整個流程涉及到多個的模塊、中間件以及定時任務。對日常的測試以及回歸造成了不小的困擾。首當其沖的就是影響測試進度，正常的測試流程一般是今天我先發一批數據，然后算一下大概要扣多少錢，明天來對一下扣費是否符合預期。如果測試過程中發現了一個代碼Bug，反饋給開發改完。再發一波數據，后天再來對一下。一個需求測試測試周期被拉得比較長。碰到多個結算相關的需求湊在一起測試，環境又只有一套，可能出現你發完數據以后，第二天來發現測試分支被發走了，那么昨天的數據相當于白發了。整個測試效率都非常低。

2.2、改進方案

需求測試效率低的根因是鏈路長和結算數據復雜度，因此我們的解決方案是構造不同階段、不同時間段的數據。并且將任務觸發和數據構造功能集成到一起，大大節約了測試所需時間。

2.3、功能展示

回歸方案優化

3.1、歷史手段

原有的回歸方案是全鏈路的回歸方案的，在gotest上面創建兩個執行集，一個每天定時往某個產品發送指定量的文本、圖片、視頻和音頻等數據，另外一個是校驗結果執行集，根據指定發送的量計算一個預估值，定時去校驗前一天的計費數據是否符合預估值。經過一段時間的驗證以后發現這種方案很不穩定，執行集經常報警。原因是這種全流程驗證的手段不靈活，數據多發或者少發一條都會導致實際結果不符合預估值，再者測試環境用的人比較多，任意一個依賴的模塊掛掉都會影響最終的結果。并且由于業務增值服務配置項特別多，傳統的方案每次新增用例也要在配置上花很多時間。

3.2、改進方案

因為構造數據的工具是現成的了，我們的回歸方案能不能基于現成的功能去做。通過實踐證明這個方案是可行的，通過結算工具直接構造結算數據，新的回歸方案只對結算模塊進行驗證，可能有同學有疑問？你的回歸方案只保障了結算模塊的邏輯，如何保障全鏈路沒有問題呢。我這里先賣個關子，我們后面再講。

3.3、功能展示

線上監控建設

4.1、線上問題分析

工欲善其事必先利其器，想要解決問題，就需要先分析問題，團隊內部首先將近三年結算相關的線上問題撈出來，然后根據這些問題產生的原因，將問題進行分類，根據是否存在資損風險大致分為兩類，有資損風險的和沒資損風險的。然后再將有資損風險的進行細分類，一共分為三種：數據統計、套餐結算、配置轉換。我們的目標就先覆蓋這三類問題。

4.2、線上案例舉例

4.2.1、案例一

問題現象：文檔解決方案結算數據偏多

問題原因：經排查發現是因為kafka數據重復消費導致的，kafka client每次會批量拉取max-poll-records的數據下來處理，如果在max.poll.interval.ms時間內未處理完，kafka會認為client掛了并移除掉，然后觸發reblance，這時候如果超時的client未提交offset，則可能導致數據重復消費

4.2.2、案例二

問題現象：新增音頻檢測場景計費偏多

問題原因：結算代碼對新增的音頻場景計算錯誤，應該是按照分鐘去計算（數據量/60 * 單價），實際上是按次去計算（數據量*單價）。導致計算結果偏大。

4.3、線上監控設計目標

4.4、方案設計

通過歷史bug的回溯，我們總結出了絕大部分問題產生的原因，那么基于此，我們設計了一套全流程對賬的方案，方案的核心在于：

1、獨立維護一套業務配置映射計費系數

2、使用和結算流程不一樣的數據源

3、設計一套類似的結算方法

通過這種方法就能保證，這個三個地方任何一個點出問題，最后的結果都會有差異，從而起到監控的作用

4.5、優化迭代

最初設計的方案肯定是不完美的，覆蓋的場景有限并且計算結果和真實的結果有一定誤差，因此需要不斷去優化，如何去優化呢？目前我們的迭代方案是 添加更多的產品監控->找出有誤差的產品->分析誤差的原因->優化誤差，誤差的原因和我們的方案設計一樣，分為三種，分別是配置問題、算法問題和數據源問題。

以我們已經解決過的幾個問題為例：

1、配置問題：原始的方案是添加監控的時候讀一次配置，后來配置發送變化沒有同步，導致最終結果對不上。優化接入業務jar包，監聽配置變更，配置持久化入庫。

2、算法優化

3、數據源優化：圖片檢測gif圖時，是根據真實檢測數去計費，這個檢測數沒有存到業務方的數據庫，真實計費用的這個檢測數，導致數據源查出來的數據偏小，已經提需求給開發同學優化。

總結

對以上內容進行一個總結：

1、測試工具提效：
支持各種階段數據構造
定時同步最新計費場景
提供對外API供其他業務部門調用
2、回歸任務優化：
只對結算模塊進行回歸
通過代碼覆蓋率評估回歸用例完備性
3、線上監控系統建設：
每日對客戶結算數據就行對賬
支持歷史數據回溯
異常客戶報警

收益以及產出

線上對賬系統上線一個季度后累計發現兩個線上BUG，一個故障。
【線上監控報警】結算歸檔數據結算出錯
【線上BUG】包量套餐超量扣費場景歸檔數據計算不對
【故障】點播音視頻數據漏結算問題復盤

測試工具以及回歸用例提效明顯
手工測試效率
2d->4h
自動化用例新增&維護成本
4h->0.5h

未來規劃

未來的規劃主要分為三個方向

橫向擴展：接入更多子服務（目前接入子服務：反垃圾、反外掛、驗證碼）
縱向擴展：目前線上監控做的內容是針對我們的客戶進行對賬，同時我們有很多服務接入的外部供應商，這個部分目前是缺少監控的，也會造成資損問題。后續也會將供應商的監控納入范圍。
降噪，減少誤報

總結

以上是生活随笔為你收集整理的知物由学 | 易盾SaaS系统资损防控体系建设的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。