背景
古人云：玩歸玩，鬧歸鬧，千萬別拿權益開玩笑。抽獎是日常營銷活動中常見的業務場景，它能夠給我們帶來巨大的業務增量，無論是對拉新、留存還是變現，都有較強的正向作用。閒魚目前已有一套較爲成熟的抽獎體系，但是隨着時間的推移以及人員的迭代，歷史的包袱已經日益沉重，資損的風險也是與日俱增，開發、測試、運營在進行日常抽獎業務搭建的時候，都深刻體會到了很多的痛點。本文主要展開介紹其中的一個痛點：資損風險及解決方案。
*資損：因某些不正確的操作或存在漏洞的代碼片段引發的集團資金損失。
資損風險場景
一個常規的抽獎需求往往需要運營、測試、開發三方的參與，常見的流程如下：
開發風險
對於開發來說，需要開發一個全新的抽獎模塊，以便連接底層權益平臺和上層頁面展示，這個模塊除了頁面佈局、UI樣式等基礎邏輯，還需要包含權益相關內容，多個模塊間可能會包含類似的權益邏輯，比如大轉盤抽獎和刮刮樂抽獎，都是抽不同金額的消費券，所以多個模塊間可能會進行重複性代碼工作，此時往往會有較多的複製粘貼場景，而複製本身是一個高效卻不安全的行爲，這就給業務場景埋下了無聲的地雷，可能某一次不小心的疏忽就導致了潛在的資損。（下圖爲常見的模塊開發場景）
運營風險
對於運營來說，首先要在權益平臺進行權益配置，包括但不限於權益內容（如權益類型、投放渠道、投放計劃等）、定向配置（如人羣配置、前置任務配置等）、活動配置（如活動基本信息、可領次數等）。當完成權益配置後，需要在運營搭建平臺進行頁面搭建，此時會使用到開發提供的抽獎模塊，並進行權益內容的二次配置，搭建平臺的權益配置仍然繁瑣及複雜，且和UI配置耦合嚴重，一次發佈行爲會同時發佈頁面元素內容和權益配置內容，哪怕只是變動了按鈕顏色，也有可能因爲權益變更引發資損風險。如下圖所示，運營的頁面變動有時候是較爲頻繁的，一旦用戶數據不理想，就會進行頁面調整實驗，比如調個按鈕位置、調個背景圖片、調個標題文案，而目前UI和權益是強耦合的，所以每一次變動，都有引發資損的可能。
測試風險
對於測試來說，在進行權益測試時，並沒有一個直觀的調試界面，當發現權益領取異常後，會聯繫開發定位，而開發其實也很難進行問題定位，因爲模塊開發可能已經過去了很久，甚至開發人員已經進行了更替，此時只能從頭到尾一點點進行全鏈路排查，往往會消耗大量的時間，而測試也只能看到最終結果，中間的執行過程是否正常其實並沒有辦法進行定位，這其實是不安全的。
運行風險
對於線上正在運行的抽獎業務，目前並沒有完善的對賬和監控體系，也就是說，目前缺少問題自動追蹤和自動告警的能力，如果出現異常，會比較被動，解決問題的時間會大幅拉長，用戶投訴的次數會顯著變高。
解決方案
其實上述流程存在的一個關鍵問題就是冗餘，權益邏輯不僅在權益平臺進行配置管理，還會在多個抽獎模塊、多個抽獎頁面進行大量重複性配置，在多人協作和工作交接的過程中，風險就會不斷地上升，所以解決問題的核心，就是要剔除不必要的冗餘，做到風險隔離，權益收斂，統一入口，詳細方案如下：
權益獨立風險
針對運營的變更風險，我們將所有的權益邏輯從原有的搭建體系內抽離，在新的平臺上進行統一權益管理。在頁面搭建層只暴露權益ID，通過ID銜接整個抽獎流程，運營在搭建頁面時，可以只關注頁面內容配置，而不再需要關心權益邏輯，單次發佈只會影響UI展示，而不會影響底層權益邏輯，可以極大地降低頁面變更風險及新人學習成本。爲了最大程度的保障權益安全和責任定位，我們實行了嚴格的權限控制，只有創建者才能進行權益變更，他人可進行權益查看、權益拷貝等，但無編輯、刪除權限，以防他人的誤操作引發不必要的麻煩。且權益的變更不會立刻同步到線上，默認會變更到預發環境，在進行測試迴歸正常後纔可進行上線操作。流程示意圖如下：
提供抽獎SDK
解決代碼冗餘最佳的方案就是做純邏輯抽離封裝，針對閒魚大部分抽獎場景和抽獎類型，我們進行了抽獎SDK的統一封裝。抽獎SDK連通了底層抽獎服務和上層業務應用，提供了一鍵接入方式，並且完全兼容常規h5及weex環境。接口設計：抽獎常見的需求就是抽獎資格查詢、抽獎狀態查詢和執行抽獎行爲，所以我們提供瞭如下接口：
isDrawing: 是否正在進行抽獎，用於判斷此次抽獎行爲狀態
canIDraw：可一鍵查詢該用戶是否符合抽獎條件，以便與展示不同的頁面元素
draw：執行抽獎，返回Promise對象
mockDrawData: 模擬抽獎行爲
mockDrawFail：模擬抽獎失敗
爲了最大程度地減少業務代碼量，我們隱藏了所有關於權益的底層調用，讓抽獎邏輯更加抽象化、更加語義化，常見的使用方式如下，開發可以通過抽獎SDK快速對接權益運營平臺，不再需要關心底層權益邏輯，大大減少了代碼成本和操作風險。
日誌迴流顯示
爲了縮短測試路徑、加快問題定位，我們提供了實時日誌功能，在權益管理平臺可通過掃描二維碼查看實時日誌迴流，用戶的每一次操作，都將拆分成極小的粒度進行監控和統計，可以非常直觀地看到每一個子節點的狀態和說明。如下圖所示，一個完成的測試鏈路爲：在運營平臺掃碼查看權益頁面 -> 在權益頁面進行抽獎行爲 -> 抽獎服務自動上報各節點日誌到日誌服務 -> 日誌服務自動推送日誌到權益管理平臺 -> 測試可在權益管理平臺查看可視化日誌。如果某個節點出現異常，會自動高亮並給出詳細異常原因。可觀測粒度更細、更直接，有利於開發和測試的問題定位和排查，大幅提高效率的同時也提高了一定的安全性。
對賬&監控
除了完善上線前的穩定性建設，上線後的穩定性同樣重要，就此新增對抽獎各個環節的監控和日誌統計，各個監控點如下圖所示，當監控出現報警時會自動提醒相關責任人，以求最快的速度定位並解決問題，運營也可以在報表平臺查看監控報表，從而可以更直觀地查看線上活動的運行情況。
效果
針對之前所闡述的風險點，已經有了明顯的成效：
我們抽離了權益相關的概念，頁面搭建時所需配置的內容明顯減少，平均配置時間減少50%+。
搭建頁面時不再涉及權益邏輯，抽獎安全性大幅上升，頁面變動發佈零風險。
通過日誌迴流功能使得測試鏈路變得更加簡單、更加直觀，測試溝通成本由0.5人天降爲0人天。
新增線上對賬和監控，24小時保障線上安全。
通過抽獎SDK給前端模塊瘦身，開發可一鍵接入權益平臺，無風險更高效。
總結
在業務日趨成熟和完善的當下，穩定性儼然成爲了首要考慮的問題，今年閒魚團隊也做了很多方向的穩定性建設，抽獎只是多個穩定性建設中的一環，我們致力於打造絕對安全、無線上故障的閒魚技術生態。目前抽獎穩定性建設已完成並逐漸對外開放，未來閒魚權益體系都將收斂於該平臺中，老的體系和已上線的業務不再更新，新的業務需求都將對接新的抽獎體系，後續在不斷地使用過程中也會持續優化，我們希望我們的抽獎平臺能夠服務於所有閒魚業務甚至淘系業務。
閒魚技術團隊不僅是阿里巴巴集團旗下閒置交易社區的創造者，更是移動與高併發大數據應用新技術的引導者與創新者。我們與Google Flutter/Dart小組密切合作，爲社區貢獻了多個高star的項目和大量PR。我們正在積極探索深度學習和視覺技術在互動、交易、社區場景的創新應用。閒魚技術與集團中間件團隊共同打造的FaaS平臺每天支持數以千萬級用戶的高併發訪問場景。
就是現在！客戶端／服務端java／架構／前端／質量工程師面向社會+校園招聘，base杭州阿里巴巴西溪園區，一起做有創想空間的社區產品、做深度頂級的開源項目，一起拓展技術邊界成就極致！
*投餵簡歷給小閒魚→[email protected]
開源項目、峯會直擊、關鍵洞察、深度解讀
請認準閒魚技術