玩歸玩，鬧歸鬧，别拿抽獎開玩笑

作者：閑魚技術-胖仔

背景

古人雲：玩歸玩，鬧歸鬧，千萬别拿權益開玩笑。抽獎是日常營銷活動中常見的業務場景，它能夠給我們帶來巨大的業務增量，無論是對拉新、留存還是變現，都有較強的正向作用。閑魚目前已有一套較為成熟的抽獎體系，但是随着時間的推移以及人員的疊代，曆史的包袱已經日益沉重，資損的風險也是與日俱增，開發、測試、營運在進行日常抽獎業務搭建的時候，都深刻體會到了很多的痛點。本文主要展開介紹其中的一個痛點：資損風險及解決方案。

*資損：因某些不正确的操作或存在漏洞的代碼片段引發的集團資金損失。

資損風險場景

一個正常的抽獎需求往往需要營運、測試、開發三方的參與，常見的流程如下：

開發風險

對于開發來說，需要開發一個全新的抽獎子產品，以便連接配接底層權益平台和上層頁面展示，這個子產品除了頁面布局、UI樣式等基礎邏輯，還需要包含權益相關内容，多個子產品間可能會包含類似的權益邏輯，比如大轉盤抽獎和刮刮樂抽獎，都是抽不同金額的消費券，是以多個子產品間可能會進行重複性代碼工作，此時往往會有較多的複制粘貼場景，而複制本身是一個高效卻不安全的行為，這就給業務場景埋下了無聲的地雷，可能某一次不小心的疏忽就導緻了潛在的資損。（下圖為常見的子產品開發場景）

營運風險

對于營運來說，首先要在權益平台進行權益配置，包括但不限于權益内容（如權益類型、投放管道、投放計劃等）、定向配置（如人群配置、前置任務配置等）、活動配置（如活動基本資訊、可領次數等）。當完成權益配置後，需要在營運搭建平台進行頁面搭建，此時會使用到開發提供的抽獎子產品，并進行權益内容的二次配置，搭建平台的權益配置仍然繁瑣及複雜，且和UI配置耦合嚴重，一次釋出行為會同時釋出頁面元素内容和權益配置内容，哪怕隻是變動了按鈕顔色，也有可能因為權益變更引發資損風險。

如下圖所示，營運的頁面變動有時候是較為頻繁的，一旦使用者資料不理想，就會進行頁面調整實驗，比如調個按鈕位置、調個背景圖檔、調個标題文案，而目前UI和權益是強耦合的，是以每一次變動，都有引發資損的可能。

測試風險

對于測試來說，在進行權益測試時，并沒有一個直覺的調試界面，當發現權益領取異常後，會聯系開發定位，而開發其實也很難進行問題定位，因為子產品開發可能已經過去了很久，甚至開發人員已經進行了更替，此時隻能從頭到尾一點點進行全鍊路排查，往往會消耗大量的時間，而測試也隻能看到最終結果，中間的執行過程是否正常其實并沒有辦法進行定位，這其實是不安全的。

運作風險

對于線上正在運作的抽獎業務，目前并沒有完善的對賬和監控體系，也就是說，目前缺少問題自動追蹤和自動告警的能力，如果出現異常，會比較被動，解決問題的時間會大幅拉長，使用者投訴的次數會顯著變高。

解決方案

其實上述流程存在的一個關鍵問題就是備援，權益邏輯不僅在權益平台進行配置管理，還會在多個抽獎子產品、多個抽獎頁面進行大量重複性配置，在多人協作和工作交接的過程中，風險就會不斷地上升，是以解決問題的核心，就是要剔除不必要的備援，做到風險隔離，權益收斂，統一入口，詳細方案如下：

權益獨立管理

針對營運的變更風險，我們将所有的權益邏輯從原有的搭建體系内抽離，在新的平台上進行統一權益管理。在頁面搭建層隻暴露權益ID，通過ID銜接整個抽獎流程，營運在搭建頁面時，可以隻關注頁面内容配置，而不再需要關心權益邏輯，單次釋出隻會影響UI展示，而不會影響底層權益邏輯，可以極大地降低頁面變更風險及新人學習成本。

為了最大程度的保障權益安全和責任定位，我們實行了嚴格的權限控制，隻有建立者才能進行權益變更，他人可進行權益檢視、權益拷貝等，但無編輯、删除權限，以防他人的誤操作引發不必要的麻煩。且權益的變更不會立刻同步到線上，預設會變更到預發環境，在進行測試回歸正常後才可進行上線操作。流程示意圖如下：

提供抽獎SDK

解決代碼備援最佳的方案就是做純邏輯抽離封裝，針對閑魚大部分抽獎場景和抽獎類型，我們進行了抽獎SDK的統一封裝。抽獎SDK連通了底層抽獎服務和上層業務應用，提供了一鍵接入方式，并且完全相容正常h5及weex環境。

接口設計：抽獎常見的需求就是抽獎資格查詢、抽獎狀态查詢和執行抽獎行為，是以我們提供了如下接口：

• isDrawing: 是否正在進行抽獎，用于判斷此次抽獎行為狀态
• canIDraw：可一鍵查詢該使用者是否符合抽獎條件，以便與展示不同的頁面元素
• draw：執行抽獎，傳回Promise對象
• mockDrawData: 模拟抽獎行為
• mockDrawFail：模拟抽獎失敗

為了最大程度地減少業務代碼量，我們隐藏了所有關于權益的底層調用，讓抽獎邏輯更加抽象化、更加語義化，常見的使用方式如下，開發可以通過抽獎SDK快速對接權益營運平台，不再需要關心底層權益邏輯，大大減少了代碼成本和操作風險。

// DEMO示範
// 複雜的權益邏輯都将收斂于 fin-olivier 中
import Olivier from '@ali/fin-olivier';

const olivier = new Olivier({ activityId: 12345 });

// 判斷抽獎資格
olivier.canIDraw().then(() => {
  // 執行抽獎
  olivier.draw().then(() => {
    // success
  }).catch(() => {
    // error
  });
});           

日志回流展示

為了縮短測試路徑、加快問題定位，我們提供了實時日志功能，在權益管理平台可通過掃描二維碼檢視實時日志回流，使用者的每一次操作，都将拆分成極小的粒度進行監控和統計，可以非常直覺地看到每一個子節點的狀态和說明。

如下圖所示，一個完成的測試鍊路為：在營運平台掃碼檢視權益頁面 -> 在權益頁面進行抽獎行為 -> 抽獎服務自動上報各節點日志到日志服務 -> 日志服務自動推送日志到權益管理平台 -> 測試可在權益管理平台檢視可視化日志。如果某個節點出現異常，會自動高亮并給出詳細異常原因。可觀測粒度更細、更直接，有利于開發和測試的問題定位和排查，大幅提高效率的同時也提高了一定的安全性。

對賬 & 監控

除了完善上線前的穩定性建設，上線後的穩定性同樣重要，就此新增對抽獎各個環節的監控和日志統計，各個監控點如下圖所示，當監控出現報警時會自動提醒相關責任人，以求最快的速度定位并解決問題，營運也可以在報表平台檢視監控報表，進而可以更直覺地檢視線上活動的運作情況。

效果

針對之前所闡述的風險點，已經有了明顯的成效：

1. 我們抽離了權益相關的概念，頁面搭建時所需配置的内容明顯減少，平均配置時間減少50%+。
2. 搭建頁面時不再涉及權益邏輯，抽獎安全性大幅上升，頁面變動釋出零風險。
3. 通過日志回流功能使得測試鍊路變得更加簡單、更加直覺，測試溝通成本由0.5人天降為0人天。
4. 新增線上對賬和監控，24小時保障線上安全。
5. 通過抽獎SDK給前端子產品瘦身，開發可一鍵接入權益平台，無風險更高效。

總結

在業務日趨成熟和完善的當下，穩定性俨然成為了首要考慮的問題，今年閑魚團隊也做了很多方向的穩定性建設，抽獎隻是多個穩定性建設中的一環，我們緻力于打造絕對安全、無線上故障的閑魚技術生态。

目前抽獎穩定性建設已完成并逐漸對外開放，未來閑魚權益體系都将收斂于該平台中，老的體系和已上線的業務不再更新，新的業務需求都将對接新的抽獎體系，後續在不斷地使用過程中也會持續優化，我們希望我們的抽獎平台能夠服務于所有閑魚業務甚至淘系業務。