作者：蘇世_
https://juejin.cn/post/7113502041342738439
這是一個悲傷的故事，也是教訓最深刻的一次。發生在 2022 年 1 月份，春節前幾周。在聊這個事之前，我想借用美團的一個案例作為切入點。
（我們公司不是美團的這種業務，但也利用了會員發券這種機制，都是在代支付勾選會員産生待使用的券，最後選擇使用，這裡我就拿美團來講）
先來看下面這幅圖，大家點外賣再熟悉不過的一個頁面！
當勾選開通會員時，系統會自動給你發 6 張優惠券（取消勾選，則 6 張券消失）
那麼問題來了，這 6 證券是怎樣的一種方式存在？
因為這裡要考慮到，使用者勾選隻是勾選，還沒有真正地發到使用者錢包裡，隻有使用者支付了，才能真正給使用者發送，這裡面就牽扯到這個臨時資料怎麼處理更好
我想了想，無非三種
- 前端自己生成資料，給後端規約傳參
- 背景落 noSql，使用者在選擇券的時候，背景查詢優惠券接口會把 noSql 裡的東西也帶上
- 背景存關系型資料庫，這裡就會牽扯到太多的垃圾資料，因為很多使用者可能隻是勾選，并不會購買
大的方面應該就這三種，至于細節，那各憑本事，看誰處理得好。
最難的需求
時間拉回到今年 1 月份，這是春節前最悠哉的時光，年終獎都定好了！
忽然開會說要在待支付界面引入會員機制，周期為一周，快速上線，要先看資料。根據資料節後再做調整。沒給開發留一點點評估的時間，還沒容得上我們說話，就。
這裡簡單說下需求吧：
平台會員原來就有，隻是沒有接入到待支付，原來購買平台會員發兩張券，這次到待支付要根據使用者不同的屬性發送不同的券，張數也不盡相同
作為産品部的技術負責人，在這個周期範圍内，首要做的就是看如何快速上線，我和産品商量看了很多需求，原型設計上的很多細節都包括在内，否則幹死都不一定能上線（天下産品都一樣，研發不硬，産品必欺。但這次是營運是拿着尚方寶劍給産品下的指令，時間既然是不能變的，那就隻能把需求點減到最少）
就這樣，技術方案用了最簡單的，也是最不安全的，沒錯，全部交給前端去生成券的資料。金額都是寫死的，說白了，就是前端按照 ui 圖出的，背景沒有出接口，因為在整體支付流程還有大量工作需要因為平台會員的介入而有大量工作（别說不專業，沒辦法）。
是以，減免多少錢，是由前端傳的（這裡可能很多人會笑話我，因為沒有一家是前端傳金額的，是的，我們做了）
看到這裡肯定有人說，雖然不合理，但是應該也不會有大問題啊。
可是問題就是爆發出來了。我們有一種券，叫”全免券“，就可以免掉本次費用。前端因為很多資料寫死了，結果這個全免券沒有考慮進去。測試當時測試的時候也忽略了，導緻線上在某種情況下會走全免券的機制
黑色星期五
我們任何上線的時間都會定到周四晚上，因為周四更新，周五如果有問題，可以處理回退。
清晨睡得正香，電話響了，一看群裡，炸鍋了。我們的使用者端主要是微信小程式，了解的都知道有個稽核期，背景服務晚上更新好之後，小程式是早上運維給稽核通過的。
結果營運早上看到很多資料，好多使用者支付都是 0 元，對比一看全都購買過平台會員。頓時我就沒有了睡意，趕緊通知運維把小程式回退到上一個版本（幸虧背景接口相容處理得當）
問題就是 A 類使用者在 B 種情況下，傳到背景就是走全免券的邏輯。
頓時“精神抖擻”的我收拾收拾背包去公司了
最後好像營運給出一個資料，3 萬左右。我私下裡也大概算了下。
年終獎整個 team 都削了點，包括我們部分老大，包括測試。主要責任在我，方案是我定的，确實不是最佳選擇。
總結教訓
這确實是我入行以來最大的 bug，作為負責人沒有處理好可能出現的問題，從方案到落地，需要慎之又慎。
協調各部門，統籌方案。
也給産品和營運個教訓吧。就說到這裡吧，希望給大家點經驗，祝大家寫不出八阿哥！