對拼多多事件的思考，理解流程爲什麼如此重要

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

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

漏洞從凌晨被羊毛黨發現，5點左右擴散傳播到網絡，10點左右修復。聽說內部仍是由於程序員發現併發異常才發現的，這翻車操做。。。

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

發佈流程

每一次測試完QA環境以後，而後還要上預發佈環境測試，一開始我也是以爲很不理解的。預發佈環境是跟生產環境配置如出一轍的系統，只是不對外啓用，站點配置的訪問權限通常都是針對內外的。

跟開發環境不一樣，預發佈環境不容許開發人員直接接觸，修改配置和發佈都須要經過運維。都是有記錄，可回滾的操做。 而直接修改數據庫，那是不可能的。每個改動都須要提工單，層層審批，最後提交運維執行。

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

審批流程

這裏主要想說的是業務後臺的管理流程。沒有從事過相關工做，對於優惠券發放流程都是想固然的。固然不一樣公司會有些出入，可是總體流程都是類似的。

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

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

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

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

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

風控管理

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

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

總結

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

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

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

本文同步發表在公衆號文章 對拼多多事件的思考，理解流程爲什麼如此重要

1. 博客是我學習過程的輸出，但願你有所收穫。
2. 有想法請留言，共同探討學習。
3. 因爲博主能力有限，文中可能存在描述不正確，歡迎指正、補充！
4. 你也能夠關注個人公衆號：ProgramLife042，名稱：風之程序人生，方便接收最新內容。