前言
今天IT界最火的新闻莫过于拼多多被褥羊毛事件，损失达到千万级别。新闻链接：拼多多公布“优惠券漏洞”案件进展：上海警方已成立专案组。
从披露的信息来看，此优惠券是拼多多与江苏卫视《非诚勿扰》合作时，因节目录制需要特殊生成的优惠券类型，被生成二维码传播领取。
漏洞从凌晨被羊毛党发现，5点左右扩散传播到网络，10点左右修复。据说内部还是因为程序员发现并发异常才发现的，这翻车操作。。。
作为一名互联网电商行业的程序员，我针对公司目前的一些流程有了新的认识。
发布流程
每一次测试完QA环境之后，然后还要上预发布环境测试，一开始我也是觉得很不理解的。预发布环境是跟生产环境配置一模一样的系统，只是不对外启用，站点配置的访问权限一般都是针对内外的。
跟开发环境不同，预发布环境不允许开发人员直接接触，修改配置和发布都需要通过运维。都是有记录，可回滚的操作。 而直接修改数据库，那是不可能的。每一个改动都需要提工单，层层审批，最后提交运维执行。
App上线，正式版本测试通过后，也是经过小应用市场投放，产品验收，业务试单，灰度测试一段时间，监控后台数据正常才会在各个应用市场投放。
审批流程
这里主要想说的是业务后台的管理流程。没有从事过相关工作，对于优惠券发放流程都是想当然的。当然不同公司会有些出入，但是整体流程都是相似的。
一张优惠券从申请到上线需要经过多个系统。有效期，适用用范围，优惠方式，数量，活动目标，这几个内容应该是申请审批的重点。
针对拼多多这张爆出问题的优惠券，我做一个表格：
看了这个优惠券的数据，几千万真金白银还敢批的，也是够可以的。就算是烧钱，这种力度没有老板亲自批谁也不敢承担责任啊。
因此，这种券在生产环境造出来就是一个定时炸弹。我就更加理解为何我们试单财务单证每次都是只提供几张正式环境的优惠券，使用后正式上线前，还要对数据进行清洗。
风控管理
这个不方便展开，简单说说思路：
- 前端用户使用优惠参与活动等黑名单风险识别
- 下单风险识别，自动拦截风险订单人工客服处理
- 业务BI数据指标监控告警
- 核心业务链路人员管理
- 线上事件管理流程
总结
电商行业是灰黑产的重灾区，业务设计从源头上就需要考虑到多种复杂的流程漏洞问题。如何风险监控，最大程度降低损失，值得我们每一个人深思。
作为程序谁也不敢保证没有Bug，关键就是如果在设计，开发，测试，运营过程中对暴露的Bug迅速响应，有一套规则去处理，减少损失，而不能祈求道德和法律层面的自觉。
也期待拼多多事件从法律上可以给出一个判例，毕竟几千万啊，呵呵，普通公司也就直接破产了。
本文同步发表在公众号文章 对拼多多事件的思考，理解流程为何如此重要