拼多多技術事故復盤，程序員應該學到什麼？

作者 | 范學雷

編輯 | 李佳

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

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

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

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

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

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

好多人羊毛弄了幾十萬；

這張券是測試券；

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

運維發現系統爆了，超過了閾值；

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

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

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

優惠券的設計問題

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

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

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

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

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

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

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

混亂的研發和運維

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

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

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

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

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

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

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

我們該怎麼做？

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

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

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

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

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

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

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

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

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

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

沒出問題的時候，你永遠也不知道代碼質量有多重要。范學雷老師教你如何寫出安全高效的代碼，請關注極客時間《代碼精進之路》專欄。

點個好看少個 bug

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！