對拼多多事件的思考,理解流程為何如此重要
前言
今天IT界最火的新聞莫過於拼多多被褥羊毛事件,損失達到千萬級別。 新聞連結:拼多多公佈“優惠券漏洞”案件進展:上海警方已成立專案組 。
從披露的資訊來看,此優惠券是拼多多與江蘇衛視《非誠勿擾》合作時,因節目錄制需要特殊生成的優惠券型別,被生成二維碼傳播領取。
漏洞從凌晨被羊毛黨發現,5點左右擴散傳播到網路,10點左右修復。據說內部還是因為程式設計師發現併發異常才發現的,這翻車操作。。。
作為一名網際網路電商行業的程式設計師,我針對公司目前的一些流程有了新的認識。
釋出流程
每一次測試完QA環境之後,然後還要上預釋出環境測試,一開始我也是覺得很不理解的。預釋出環境是跟生產環境配置一模一樣的系統,只是 不對外啟用 ,站點配置的訪問許可權一般都是針對內外的。
跟開發環境不同,預釋出環境不允許開發人員直接接觸,修改配置和釋出都需要通過運維。都是有記錄,可回滾的操作。而直接修改資料庫,那是不可能的。每一個改動都需要提工單,層層審批,最後提交運維執行。
App上線,正式版本測試通過後,也是經過小應用市場投放,產品驗收,業務試單,灰度測試一段時間,監控後臺資料正常才會在各個應用市場投放。
審批流程
這裡主要想說的是業務後臺的管理流程。沒有從事過相關工作,對於優惠券發放流程都是想當然的。當然不同公司會有些出入,但是整體流程都是相似的。
一張優惠券從申請到上線需要經過多個系統。有效期,適用用範圍,優惠方式,數量,活動目標,這幾個內容應該是申請審批的重點。

針對拼多多這張爆出問題的優惠券,我做一個表格:
專案 | 內容 |
---|---|
有效期 | 2019.01.20-2020.01.20 |
適用範圍 | 全網 |
限制 | 無門檻 |
優惠方式 | 減 100 元 |
數量 | 沒有限制,或至少幾十萬張 |
看了這個優惠券的資料,幾千萬真金白銀還敢批的,也是夠可以的。就算是燒錢,這種力度沒有老闆親自批誰也不敢承擔責任啊。
因此,這種券在生產環境造出來就是一個 定時炸彈 。我就更加理解為何我們試單財務單證每次都是隻提供幾張正式環境的優惠券,使用後正式上線前,還要對資料進行清洗。
風控管理
這個不方便展開,簡單說說思路:
- 前端使用者使用優惠參與活動等黑名單風險識別
- 下單風險識別,自動攔截風險訂單人工客服處理
- 業務BI資料指標監控告警
- 核心業務鏈路人員管理
- 線上事件管理流程
總結
電商行業是灰黑產的重災區,業務設計從源頭上就需要考慮到多種複雜的流程漏洞問題。如何風險監控,最大程度降低損失,值得我們每一個人深思。
作為程式誰也不敢保證沒有Bug,關鍵就是如果在設計,開發,測試,運營過程中對暴露的Bug迅速響應,有一套規則去處理,減少損失,而不能祈求道德和法律層面的自覺。
也期待拼多多事件從法律上可以給出一個判例,畢竟幾千萬啊,呵呵,普通公司也就直接破產了。
本文同步發表在公眾號文章 對拼多多事件的思考,理解流程為何如此重要
- 部落格是我學習過程的輸出,希望你有所收穫。
- 有想法請留言,共同探討學習。
- 由於博主能力有限,文中可能存在描述不正確,歡迎指正、補充!
- 你也可以關注我的公眾號: ProgramLife042 ,名稱: 風之程式人生 ,方便接收最新內容。