短短 1 个小时，让公司损失近 3 万

作者：苏世_ 

https://juejin.cn/post/7113502041342738439

这是一个悲伤的故事，也是教训最深刻的一次。发生在 2022 年 1 月份，春节前几周。在聊这个事之前，我想借用美团的一个案例作为切入点。

（我们公司不是美团的这种业务，但也利用了会员发券这种机制，都是在待支付勾选会员产生待使用的券，最后选择使用，这里我就拿美团来讲）

先来看下面这幅图，大家点外卖再熟悉不过的一个页面！

当勾选开通会员时，系统会自动给你发 6 张优惠券（取消勾选，则 6 张券消失）

那么问题来了，这 6 张券是怎样的一种方式存在？

因为这里要考虑到，用户勾选只是勾选，还没有真正的发到用户钱包里，只有用户支付了，才能真正给用户发送，这里面就牵扯到这个临时数据怎么处理更好

我想了想，无非三种

• 前端自己生成数据，给后端规约传参

• 后台落 noSql，用户在选择券的时候，后台查询优惠券接口会把 noSql 里的东西也带上

• 后台存关系型数据库，这里就会牵扯到太多的垃圾数据，因为很多用户可能只是勾选，并不会购买

大的方面应该就这三种，至于细节，那各凭本事，看谁处理的好。

最难的需求

时间拉回到今年 1 月份，这是春节前最悠哉的时光，年终奖都定好了！

忽然开会说要在待支付界面引入会员机制，周期为一周，快速上线，要先看数据。根据数据节后再做调整。没给开发留一点点评估的时间，还没容得上我们说话，就。

这里简单说下需求吧：

平台会员原来就有，只是没有介入到待支付，原来购买平台会员发两张券，这次到待支付要根据用户不同的属性发送不同的券，张数也不尽相同

作为产品部的技术负责人，在这个周期范围内，首要做的就是看如何快速上线，我和产品商量砍了很多需求，原型设计上的很多细节都包括在内，否则干死都不一定能上线（天下产品都一样，研发不硬，产品必欺。但这次是运营是拿着尚方宝剑给产品下的命令，时间既然是不能变的，那就只能把需求点减到最少）

就这样，技术方案用了最简单的，也是最不安全的，没错，全部交给前端去生成券的数据。金额都是写死的，说白了，就是前端按照 ui 图出的，后台没有出接口，因为在整体支付流程还有大量工作需要因为平台会员的介入而有大量工作（别说不专业，没办法）。

所以，减免多少钱，是由前端传的（这里可能很多人会笑话我，因为没有一家是前端传金额的，是的，我们做了）

看到这里肯定有人说，虽然不合理，但是应该也不会有大问题啊。

可是问题就是爆发出来了。我们有一种券，叫”全免券“，就可以免掉本次费用。前端因为很多数据写死了，结果这个全免券没有考虑进去。测试当时测试的时候也忽略了，导致线上在某种情况下会走全免券的机制

黑色星期五

我们任何上线的时间都会定到周四晚上，因为周四升级，周五如果有问题，可以处理回退。

清晨睡的正香，电话响了，一看群里，炸锅了。我们的用户端主要是微信小程序，了解的都知道有个审核期，后台服务晚上升级好之后，小程序是早上运维给审核通过的。

结果运营早上看到很多数据，好多用户支付都是 0 元，对比一看全都购买过平台会员。顿时我就没有了睡意，赶紧通知运维把小程序回退到上一个版本（幸亏后台接口兼容处理得当）

问题就是 A 类用户在 B 种情况下，传到后台就是走全免券的逻辑。

顿时“精神抖擞”的我收拾收拾背包去公司了

最后好像运营给出一个数据，3 万左右。我私下里也大概算了下。

年终奖整个 team 都削了点，包括我们部分老大，包括测试。主要责任在我，方案是我定的，确实不是最佳选择。

总结教训

这确实是我入行以来最大的 bug，作为负责人没有处理好可能出现的问题，从方案到落地，需要慎之又慎。

协调各部门，统筹方案。

也给产品和运营个教训吧。就说到这里吧，希望给大家点经验，祝大家写不出八阿哥！