拼多多技術事故複盤，程式設計師該學到什麼？

每起事故都是在倒逼技術團隊成長，沒有誰能保證不寫 Bug 不出錯，我們要做的，是在事故發生以後，找到問題的根源，及時填坑止損。

2019 年 1 月 20 日凌晨，有網友稱拼多多出現重大 Bug，100 元無門檻券用戶可以隨便領取並進行消費。大家爭相傳播，大半夜的都起來領券，有的用戶甚至領了上千張。機靈的用戶，以最快的速度花掉了優惠券，例如給中國移動儲值。

相關文章推薦：程式設計師導致拼多多出現重大Bug，被薅上千萬

拼多多凌晨回應，「有黑灰產團夥通過一個過期的優惠券漏洞盜取數千萬元平台優惠券，進行不正當牟利。針對此行為，平台已第一時間修復漏洞，並正對涉事訂單進行溯源追踪。同時我們已向公安機關報案，並將積極配合相關部門對涉事黑灰產團夥予以打擊。」

隨後，拼多多發言人表示，實際最終資產損失或低於千萬人民幣。

這個事情發生後，在技術圈炸開了鍋，可能是源自於傳言的「一個 bug 可能會為公司帶來 200 億的損失」。

身為程式設計師，我更關心的是，這個 bug 到底是怎麼來的呢？根據市場傳言，我們大致可以得到以下的一些線索。這些線索的真實性還有待考證，或許並不是這次事件的真實情況，但是這也不妨礙我們透過這些線索，來探討一下這起事故給我們帶來的啟示。

  ●    好多人羊毛弄了數十萬;

  ●    這張券是測試券；

  ●    系統在凌晨自動上線測試券；

  ●    系統在凌晨自動上線測試券；

#  ●    運維發現系統爆炸了，超過了門檻；

  ●    當事人手動下線了測試券；

  ●    手動下線的測試券，早上八點又上線了。

這些端倪看起來可以合理地解釋一個重大 bug 的部署和運維。從這些端倪中，除了優惠券本身的設計問題，我們也可以看到維運的混亂。測試券怎麼能夠上線呢？系統爆表了，為什麼沒有跟進風險防範措施？手動下線了的測試券，怎麼又能夠重新上線了？為什麼上​​線、下線優惠券操作這麼草率？如果一個軟體系統是這樣的維運水平，出問題是遲早的事情。如果還沒出問題，只能說運氣太好。 優惠券的設計問題

第一個吸引我們的問題是，「好多人羊毛弄了幾十萬」。這就意味著，一個人可以領用上千張優惠券。好多人這麼操作，說明無門檻券的領用，技術門檻極低。

一般的優惠券，類似折價券，都有使用門檻，例如買 100 優惠 20 元。無門檻券，顧名思義，就是沒有使用門檻的優惠券，100 元的優惠券可以買 100 元的商品，幾乎等同於現金。由於無門檻券類似現金，因此它和一般的優惠券有重大區別。

先不去管羊毛黨，拼多多號稱有 3 億用戶，如果每個用戶都合法合理地領用 100 元無門檻券，這就需要 300 億人民幣。帳戶註冊，幾乎是零門檻，如果微信 10 億用戶合法合理地註冊、領用無門檻券，給手機充個值，這就需要 1000 億人民幣。

截至昨日，拼多多市值接近 230 億美元，折合人民幣也就 1600 億的樣子。 100 元無門檻券隨便領，這看起來像是要拆了公司給大家發獎金的姿態。這肯定不是無門檻券的預期。

隨便領的無門檻券，怎麼看都不是一個合格的商業設計。最起碼，訂個數量上限吧，大家搶完就沒了，幾百萬送就送了。送幾百個億，不符合正常的商業邏輯。

一般而言，即使是一般優惠券的領取都有很多附加的條件。比如說，一個帳戶只能領取一次，或是只有新帳戶可以領取。而帳號的認證，也要有很多的安全措施，例如綁定手機號，綁定設備，使用安全連線等措施。帳戶的認證和管理，是一個服務網站最最基本的功夫。如果一個人可以領用上千張優惠券，那麼帳戶管理的這個基本功，不能算及格。帳戶的管理程度如果不及格，這個網站的風險比我們想像得還要糟糕。

###這麼糟糕的帳戶管理，這麼糟糕的商業設計，太出乎人的意料，不符合正常的邏輯。所以，我比較認同這只是一個測試券，不應該出現在正常運作的系統中。而如果真是測試券的問題，暴露的就是軟體研發和維運的混亂。 ###

混亂的研發與維運

一張測試券，居然自動上線；手動下線後，又自動上線。這樣的產品發布流程匪夷所思。一項功能的出爐，要經過設計、實現、評審、測試、審批，才能夠走到正式的系統中。這些環節，只要有一個環節發揮了作用，測試券都不可能上線，更不可能自動上線。

上線後，還要有持續的風險監控。如果系統超過了閾值爆掉，維運能夠第一時間獲得爆表的信息，比如大半夜的，帳戶異常活躍或者優惠券業務火爆，也能夠及時地截斷這個風險。

由此可見，對維運人員的合理約束機制，是一個商業公司必須謹慎對待的問題。哪能隨便一張測試券就可以直接跑到正式的系統中呢？軟體的運維，是一個需要特別關注風險管控的環節，尤其是軟體的品質沒有跟上的時候。軟體的維運事故，有時候甚至會顛覆一個產業。

2011 年，一個數位憑證簽發機構，簽發了多張數位憑證給Google。而谷歌從來沒有向這個機構申請過數位憑證。也就是說，數位憑證的持有者並不是Google。這個持有者可以冒充谷歌的網站，盜取用戶登入訊息，包括用戶名和密碼。這意味著要么這個公司技術水準有問題（駭客攻擊），要么這個公司的運維能力有問題（亂發證書）。這個安全問題在 2011 年 8 月被曝光，幾乎所有的軟體巨頭立即宣布封鎖這家機構的數位憑證。 9 月份，這家有著很大市場影響力的機構就宣布破產了。

然而，這不是最終結局，數位憑證簽發產業的厄運才剛開始。人們好像忽然體認到，資訊安全不能依賴數位憑證機構，一個 4,000 億美元市值公司的安全，不能依賴一個 40 億美元市值公司的營運能力。於是，各種各樣的新技術在隨後幾年爭相出現。這些新技術如果廣泛使用，將徹底抹掉整個數位憑證簽發產業。這樣的日子，離我們已經不遠了。現在，數位憑證簽發機構的日子過得都比較慘淡，賣的賣，散的散。

頻頻發生安全事故的順風車，從長期看，也具有類似的性質。相較之下，如果一次事故損失的只有錢，影響可能還算是可以勉強承受的。希望損失的只有錢，但是我對這個期望並不樂觀。

追本溯源，維運如此混亂，一般和軟體的品質脫不了乾系。一個正經的軟體系統，該怎麼出品、該怎麼部署、該怎麼運作、該怎麼授權、危機該怎麼處理，這些問題都要有設計、有實現、有預案。當事人設計了一個無門檻測試券，就可以在營運系統裡跑，而且還可以無限領，這暴露的是背後爛透的軟體質量，以及鬆散、無序的軟體研發流程。我們常說，優秀的軟體出自優秀的流程。混亂的研發流程，難以出品高品質的產品。

我們該怎麼做？

無知者無畏，安全問題之所以特殊，就在於它如果不發生，我們也許永遠不知道問題的存在，當然也不知道問題有多嚴重。每一次安全危機，都不該被浪費。如果我們是當事人，有哪些辦法可以避免類似的事故？

最緊急的事情，就是趕快把帳戶安全的債給還了。要不然，經過這次的傳播，一大堆的眼睛看好了這塊肥肉。駭客攻擊的下一波，也許已經在路上了。

接下來，要盡快考慮下面的幾件事。

第一件要做的事情，就是規範研發流程。 一流的軟體研發流程下出品的產品，再差也不會差到哪裡去。在這個研發流程裡，程式設計師不能單槍匹馬地蠻幹。需求要討論，設計要預覽，功能要審核，程式碼要評審，軟體要測試，系統要試營運。人人都會犯錯，每一個環節，多幾雙眼睛盯著，就大幅減少了犯錯的幾率。程式設計師也能透過研發的流程快速成長，進一步降低錯誤發生的幾率。一個好的製度，可以成就人；一個壞的製度，可以糟蹋人。

第二件要做的事情，程式碼的安全性要重視。 程式碼的安全，不都是指駭客入侵。這個無門檻券的領用，就是一個嚴重的安全事故。反映到程式碼層面，可能就是帳戶管理不安全，商業邏輯沒有校驗，維運授權管理散漫，異常風險沒有及時預警。

第三件要做的事情，商業設計要預先推演。 即使沒有駭客黑產，1000 億人民幣無門檻優惠券，也不是任何一家商業機構願意支付的成本。這是一個幼稚園等級的錯誤。如果商業邏輯不成立，也意味著有缺陷的軟體需求。建立在漏洞百出的需求上的軟體，也會是漏洞百出的。

第四件要做的事情，改進產品上線的機制。 設定產品上線的檢查點和管線，任何一個檢查點失效，管線都要中斷，產品都不能上線。這些檢查點包括產品的試營運、功能的批准、配套的監控措施等等。

第五件要做的事情，提高維運的風險防範能力。 一個有 3 億用戶，230 億美元市值，經營電子商務的公司，是駭客眼中的肥肉。尤其是用戶隱私資訊和現金流，關係到企業的生存。這種體量的公司，具有優秀的風險防範能力是最基本的要求，而不是錦上添花的東西。風險的主動偵測、及時預警、快速應對，這些措施都要跟上。

如果無門檻券的商業設計經過推演，軟體功能經過討論，實現代碼經過評審，上線經過預演，事故能夠及時預警，只要其中的任何一個環節發揮了作用，這次事故都不會這麼慘烈！

我理解一家公司不顧一切全速前進，以質量換速度的競爭壓力和動力。只是，當我們追求眼下速度的時候，也要考慮三尺以外的未來。要不然，這屁股後面累積的債，真會成為怎麼甩都甩不掉的大尾巴。