两天都在讨论拼多多可以改名叫坑多多，有人就说技术人员没责任，虽然我也是做技术的但是并不认同这种单纯把技术抛开的观点，颇有甩锅嫌疑
当然这次事件中产品设计的规则漏洞很明显，而并不是由某个安全漏洞导致的财产损失。一个价值100元的无门槛优惠券在没有审批放开的情况下就可以领取并随意兑换使用确实欠妥，如果是在我等金融机构偶尔发放几块钱甚至几毛钱的活动都要经过N层审批，而且涉及市场、电商、合规、风控和IT的多部门沟通才会觉得要不要做这个事情，甚至一个很好的红包吸引获客活动可能会因不符合监管要求涉嫌恶意诱导而终止。所以一个团队必须要有向心力才能打造安全稳定的产品，而不是在产品设计之初就互相推诿和事不关己高高挂起，除非拼多多是一个部门拍脑袋就搞出这么个活动的，否则都要打板子。
我们知道一个系统或者产品的风险管理至少要有三点，风险警提示，风险防范和风险监控。
还有一点是系统要具备的风险防范能力，当风险提示里面的没有实现或者遗漏，出现了问题怎么快速止血是第一要务。这次拼多多事件刚好在周末发生，前后花了几个小时才止住血，确实不应该。一个优惠活动有上架那至少也要有下架的能力吧，所以一个好的产品需要有一个完整的生命周期，不能只顾上线不顾下线，一方面长时间的废弃业务堆积会导致系统应用冗杂更新难度大，另一方面当初上线的活动没有下架仅仅是被新的活动替代，那么如果有人保留了以前的活动链接照样可以访问，潜在的风险巨大，显然拼多多这个产品的设计人员这方面工作没做好。
出了问题我们都想第一时间解决，但是第一时间不在现场怎么办?有天大的本事也不能瞬间移动吧，这个时候风险监控就发挥威力了，回顾这次事件拼多多都是在羊毛圈内推广开来的，随之而来的肯定是大规模的请求访问，如果有高频告警机制那么也会在事件扩大到不可收拾的地步之前发现进而拥有更多的救火黄金时间，比如，监控日志如果一分钟内有一千个请求同一个地址就告警，那么可以快速通知当事人哪里着火了，该带什么救火工具。
所以，一个好的产品，必须要安全完整，如果拼多多上面每一个环节都有了，至少可以相关人员年终奖会丰厚点吧。还有我们对待事故要有包容心和宽容心，不要人家有漏洞就幸灾乐祸，谁还不是一个过程，毕竟一个会讲故事的人也许也是经历过事故的人嘛。