「时光不负，创作不停，本文正在参与2022年中总结征文大赛
这是一个哀痛的故事，也是教训最深入的一次。发生在2022年1月份，春节前几周。在聊这个事之前，我想借用美团的一个事例作为切入点。
（咱们公司不是美团的这种事务，但也利用了会员发券这种机制，都是在待付出勾选会员产生待运用的券，最终挑选运用，这儿我就拿美团来讲）
先来看下面这幅图，咱们点外卖再了解不过的一个页面！
当勾选注册会员时，体系会自动给你发6张优惠券（取消勾选，则6张券消失）
那么问题来了，这6张券是怎样的一种方法存在？
由于这儿要考虑到，用户勾选仅仅勾选，还没有真实的发到用户钱包里，只有用户付出了，才干真实给用户发送，这儿面就牵扯到这个暂时数据怎么处理更好
我想了想，无非三种
-
后台落noSql，用户在挑选券的时分，后台查询优惠券接口会把noSql里的东西也带上
-
后台存联系型数据库，这儿就会牵扯到太多的废物数据，由于许多用户或许仅仅勾选，并不会购买
大的方面应该就这三种，至于细节，那各凭本事，看谁处理的好。
最难的需求
时刻拉回到本年1月份，这是春节前最悠哉的时光，年终奖都定好了！
遽然开会说要在待付出界面引入会员机制，周期为一周，快速上线，要先看数据。根据数据节后再做调整。没给开发留一点点评价的时刻，还没容得上咱们说话，就。。。。
这儿简略说下需求吧：
渠道会员本来就有，仅仅没有介入到待付出，本来购买渠道会员发两张券，这次到待付出要根据用户不同的属性发送不同的券，张数也不尽相同
作为产品部的技术负责人，在这个周期范围内，首要做的便是看怎么快速上线，我和产品商议砍了许多需求，原型规划上的许多细节都包含在内，否则干死都不一定能上线（天下产品都一样，研发不硬，产品必欺。但这次是运营是拿着尚方宝剑给产品下的命令，时刻既然是不能变的，那就只能把需求点减到最少）
就这样，技术计划用了最简略的，也是最不安全的，没错，全部交给前端去生成券的数据。金额都是写死的，说白了，便是前端按照ui图出的，后台没有出接口，由于在全体付出流程还有许多作业需求由于渠道会员的介入而有许多作业（甭说不专业，没办法）。
所以，减免多少钱，是由前端传的（这儿或许许多人会笑话我，由于没有一家是前端传金额的，是的，咱们做了）
看到这儿必定有人说，虽然不合理，但是应该也不会有大问题啊。
可是问题便是爆发出来了。咱们有一种券，叫”全免券“，就可以免掉本次费用。前端由于许多数据写死了，成果这个全免券没有考虑进去。测验其时测验的时分也疏忽了，导致线上在某种情况下会走全免券的机制
黑色星期五
咱们任何上线的时刻都会定到周四晚上，由于周四晋级，周五如果有问题，可以处理回退。
清晨睡的正香，电话响了，一看群里，炸锅了。咱们的用户端首要是微信小程序，了解的都知道有个审阅期，后台服务晚上晋级好之后，小程序是早上运维给审阅通过的。
成果运营早上看到许多数据，好多用户付出都是0元，对比一看全都购买过渠道会员。顿时我就没有了睡意，赶忙告诉运维把小程序回退到上一个版别（幸而后台接口兼容处理妥当）
问题便是A类用户在B种情况下，传到后台便是走全免券的逻辑。
顿时“精神抖擞”的我拾掇拾掇背包去公司了
最终好像运营给出一个数据，3万左右。我私下里也大约算了下。。。。。。
年终奖整个team都削了点，包含咱们部分老大，包含测验。首要职责在我，计划是我定的，确实不是最佳挑选。
总结教训
这确实是我入行以来最大的bug，作为负责人没有处理好或许呈现的问题，从计划到落地，需求慎之又慎。
协调各部门，统筹计划。
也给产品和运营个教训吧。就说到这儿吧，希望给咱们点经历，祝咱们写不出八阿哥
