知物由學 | 易盾SaaS系統資損防控體系建設

背景

易盾業務主要分內容安全、業務安全和移動安全三部分，內容安全主要給客戶提供反垃圾機器檢測能力，文字、圖片和音影片。並和人工稽核、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

未來規劃

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

• 橫向擴充套件：接入更多子服務（目前接入子服務：反垃圾、反外掛、驗證碼）

• 縱向擴充套件：目前線上監控做的內容是針對我們的客戶進行對賬，同時我們有很多服務接入的外部供應商，這個部分目前是缺少監控的，也會造成資損問題。後續也會將供應商的監控納入範圍。

• 降噪，減少誤報