對拼多多優惠券事件的思考，理解流程為何如此重要

前言

今天IT界最火的新聞莫過於拼多多被褥羊毛事件，損失達到千萬級別。新聞鏈接：拼多多公布“優惠券漏洞”案件進展：上海警方已成立專案組。

從披露的信息來看，此優惠券是拼多多與江蘇衛視《非誠勿擾》合作時，因節目錄制需要特殊生成的優惠券類型，被生成二維碼傳播領取。

漏洞從凌晨被羊毛黨發現，5點左右擴散傳播到網絡，10點左右修復。據說內部還是因為程序員發現並發異常才發現的，這翻車操作。。。

作為一名互聯網電商行業的程序員，我針對公司目前的一些流程有了新的認識。

發布流程

每一次測試完QA環境之后，然后還要上預發布環境測試，一開始我也是覺得很不理解的。預發布環境是跟生產環境配置一模一樣的系統，只是不對外啟用，站點配置的訪問權限一般都是針對內外的。

跟開發環境不同，預發布環境不允許開發人員直接接觸，修改配置和發布都需要通過運維。都是有記錄，可回滾的操作。 而直接修改數據庫，那是不可能的。每一個改動都需要提工單，層層審批，最后提交運維執行。

App上線，正式版本測試通過后，也是經過小應用市場投放，產品驗收，業務試單，灰度測試一段時間，監控后台數據正常才會在各個應用市場投放。

有效而規范的研發流程是軟件質量的根本保證。

審批流程

這里主要想說的是業務后台的管理流程。沒有從事過相關工作，對於優惠券發放流程都是想當然的。當然不同公司會有些出入，但是整體流程都是相似的。

一張優惠券從申請到上線需要經過多個系統。有效期，適用用范圍，優惠方式，數量，活動目標，這幾個內容應該是申請審批的重點。

針對拼多多這張爆出問題的優惠券，我做一個表格：

項目	內容
有效期	2019.01.20-2020.01.20
適用范圍	全網
限制	無門檻
優惠方式	減100元
數量	沒有限制，或至少幾十萬張

看了這個優惠券的數據，幾千萬真金白銀還敢批的，也是夠可以的。就算是燒錢，這種力度沒有老板親自批誰也不敢承擔責任啊。

因此，這種券在生產環境造出來就是一個定時炸彈。我就更加理解為何我們試單財務單證每次都是只提供幾張正式環境的優惠券，使用后正式上線前，還要對數據進行清洗。

重要節點審批，是風控扼殺危險的關鍵節點。

風控管理

這個不方便展開，簡單說說思路：

1. 前端用戶使用優惠參與活動等黑名單風險識別
2. 下單風險識別，自動攔截風險訂單人工客服處理
3. 業務BI數據指標監控告警
4. 核心業務鏈路人員管理
5. 線上事件管理流程

總結

電商行業是灰黑產的重災區，業務設計從源頭上就需要考慮到多種復雜的流程漏洞問題。如何風險監控，最大程度降低損失，值得我們每一個人深思。

作為程序誰也不敢保證沒有Bug，關鍵就是如果在設計，開發，測試，運營過程中對暴露的Bug迅速響應，有一套規則去處理，減少損失，而不能祈求道德和法律層面的自覺。

也期待拼多多事件從法律上可以給出一個判例，畢竟幾千萬啊，呵呵，普通公司也就直接破產了。

本文同步發表在公眾號文章 對拼多多事件的思考，理解流程為何如此重要