線上大事故

最近幾天我非常忙，基本從早上起來到晚上睡覺前都在工作，平均每兩個小時一個電話會，然后各種畫圖寫產品文檔。

至于原因，是我合作的一家公司出了個線上大事故。

他們公司做的是電商業務，前兩天交易系統出現異常報警，運營設置的優惠券可以被用戶反復領取。

簡單說，運營發一個 10 元無門檻優惠券，用戶用完一張后可以繼續領下一張，而且每次在平臺上買東西都能用。

活動開始兩天后，平臺訂單開始出現異常增長，GMV 也一路看漲，老板一開始還很高興，至少燒錢有效果。

可是，慢慢發現事情有點不對勁。

運營設置的優惠池不應該支持這么大體量的訂單增長，仔細查了下單筆訂單數據才發現，幾乎每一筆訂單都在用那個 10 元的無門檻優惠券，而且一個用戶使用了多次。

雖然第一時間就下線了這個優惠券，但事后一查還是發現損失了 6 位數，定位為線上事故。

事后查了下，產生這個問題的原因有多方面，既有產品的問題、也有技術的問題、還有測試和業務運營的問題。

先說產品的鍋。

領取優惠券的頁面是一個新開發的 H5 獨立頁，產品在設計和定義頁面邏輯時沒有強調「領取優惠券」按鈕被點擊且領取成功后需要置灰并不可點擊，而且 PRD 里也沒有明確定義單個用戶限領一次。

這么一來，用戶點擊一次后還可以重復點擊。

再說技術的鍋。

在正常邏輯下，上面說的是前端邏輯控制，但只要后端做了限制也不會出事。

沒想到的是，后端竟然也沒做控制。不僅沒限制用戶 ID，也沒有對優惠券使用做限制。

說實話，這就很離譜了。

只要前端按鈕點一下，后端就成功發一張優惠券，用戶把羊毛薅到爽。

還有測試的鍋。

測試在上線前沒有做充分測試，甚至連這種連續點擊的情況都沒做，直接把一個大 bug 搞到線上。

但凡仔細留意一下頁面邏輯和下單邏輯，這個問題并不難發現。

最后就是業務運營的鍋。

他們為了省事，直接把優惠券余額設置得很大，這樣就避免了每次還需要重復去增加余額。

更離譜的是，原本第一批計劃上線 500 張 10 元的優惠券，他們直接設置成了 20000 張，因為這就是本次優惠券活動的上限。

原計劃慢慢放，現在一次性放完，前后端還沒有任何邏輯限制，簡直就是開閘放水。

最最最離譜的事情來了，由這個線上事故牽出了一系列同類問題，結果就是產品全部走查。

但凡涉及到效益系統的每一個環節，都要重新過一遍，產品查、技術查、測試查。

過程中發現的問題都需要臨時補窟窿，所以工作量搞得很大。

雖然搞了幾天把大部分坑都填上了，但時候復盤還是心有余悸，因為他們這個業務發展很快，如果后面大范圍沖量時才發現這個問題，那損失就大了。

這里面也體現了產品開發過程中的一些常見問題。

比如，對 PRD 評審的不嚴謹，沒有具體的規范和原則，而且評審會上技術團隊參與程度不夠。

這個問題我在很多團隊都發現了，一個產品評審會上，技術就像去打醬油一樣，搬個電腦做自己的事，偶爾抬頭看一眼。

結果到開發階段發現一些問題，然后臨時跑過來找產品商量，原本是都可以在評審會上解決的。

當然，產品也有自己的問題，嚴謹的流程圖、交互跳轉圖、關鍵邏輯說明等，這些都需要在 PRD 里體現。

嚴格來說，測試需要根據產品設計提前去定義測試用例，盡可能遍歷各種情況，這樣才能提前捕捉問題。

還有就是業務運營，不要把系統當成保險箱，所有的設置和操作最好有自己的規則和流程。

雖然坑很多，但經歷一次還是能收獲不少東西。

怎么說呢，世界真是個草臺班子。

················· 唐韌出品 ·················

安可時刻

我發現朋友圈有不少人開啟了假期模式，甚至有的已經人在國外了。

就目前來看，我朋友圈里有人在日本、有人在新西蘭、有人在美國、有人在西班牙、有人在法國、有人在新加坡。

說實話，上班真好。像我，國慶期間大概率還是要繼續工作，但假期也準備和親戚出去帶娃玩幾天，目的地江西那邊。

請問，你們的假期準備怎么過？