“拼多多”被薅的问题出在哪儿?损失将如何买单?

DD的博客全面升级,阅读体验更佳(尤其是系列教程),后续不再通过这里发布新文章,而是改到 www.didispace.com 发布啦,奔走相告!点击直达~

难得可以一天都窝在家里写代码,没太注意朋友圈和群里的消息。下午出门打开微信,马上就被“拼多多被薅羊毛”的文章吸引了眼球。基本上把群里、朋友圈里以及各大新闻App刷了个遍,根据网上传言 + 官方回应基本就是这么个事儿:

  1. 微博爆料:拼多多出现重大Bug:100 无门槛券随便领,一晚上被薅200亿
  2. 官方回应:有黑灰产团队利用漏洞牟利,已报警处理。
  3. 官方辟谣:被薅200亿是谣言,实际损失或低于千万元

对于网络上的各种其他诸如:半夜被叫起来撸羊毛、疑似拼多多员工回应部门年终奖泡汤、不要发货对已下订单进行砍单处理等消息,由于缺乏真实性依据,就不多说了。反正,一个事实:漏洞是真的,被薅羊毛也是真的!

问题出在哪儿?

薅羊毛这个词是所有电商平台一直以来都存在的。由于电商与线下的竞争,电商与电商之间的竞争,各种优惠活动层出不穷,而此次据爆料的拼多多漏洞也出于此。对于出现此大规模问题,笔者认为可能有以下两个主要问题:

主因:逻辑漏洞 或 程序漏洞**

对于优惠券的管理,随着运营模式的花样不断增多,其内部逻辑的复杂度是非常巨大的。

这里就非常有可能产生两种问题

  1. 运营逻辑本身存在漏洞
  2. 程序实现逻辑的漏洞

对于互联网企业,人员的流动性一直以来都非常的频繁,对于优惠券这样频繁变动的模块,其实是非常容易因人员流失而导致逻辑认知上的不足而引发漏洞的产生的。特别是对于那些组合优惠,你需要考虑很多条件,如果其中某个或关系的条件被遗漏了,就极有可能出现严重的漏洞。对于拼多多这种频繁做活动的产品来说,这样的风险是比较大的。

对于这样的问题,有办法解决吗?

肯定是有的,方法其实很传统,但是很多时候,我们对于互联网产品,往往都会说为了效率,就对此不那么重视了,是什么呢?软件工程中的质量保障体系!想想大家曾经在大学学的软件工程,再想想现在所在的互联网产品开发管理,对于质量保障的管控,其实都做的不太好。由于互联网产品的生命周期原因,很多时候我们并不知道我们的产品到底能走多远,我们总是在不断的试错,而忽略了每次试错所带来的风险问题。

我曾经在金融机构和电商平台都任职过,回头想想,为什么因漏洞产生的损失问题往往都是互联网公司,而非金融机构呢?为什么都是我们这些走在技术前沿的企业,而不是那些老被嘲笑鄙视的传统企业呢?

对于传统企业,比如:银行、证券这样的金融机构,由于企业经营有明确的模式和打法,通常都不会如互联网那么激进,稳扎稳打,对于系统开发的质量管控自然是比较严格的,从需求、设计、开发、测试等环境都有非常多的要求,以保障每个系统的稳定,当然这样做也使得这些传统企业的前进步伐比较慢。而很多时候互联网产品没有什么根基,从头开始就一直都在探索之中,对于将来并没有明确的走法,所以在相同的时间里,希望可以获得更多的尝试,速度是互联网公司所倾向的,很多在软件工程管理中的要素就很容易缺失,比如:设计文档、代码质量、测试管理等。

综其原因,无非是对速度与质量的平衡选择导致。互联网产品是比较容易因为走得太快,而扯到蛋的!

次因:业务指标的监控不力**

也许说在这里,网友会说,如果我们不走得太快,可能马上也会因为找不到正确的模式而死掉。是的,这是非常残酷的问题,我们既希望保持速度,又希望有较高的质量保障,该怎么办?

本身速度与质量是想矛盾的,我们追求了高速度之后,是很难保障质量的。但是,对此我们依然还是可以做一些其他措施的。既然我们无法完美的提防因为走得太快,而扯到蛋的事实,那么我们还能做的就是,当我们扯到第一次扯到蛋时,应该及时的制止和预防下一次!。这也是本文想说的第二个原因,虽然这个不是造成本次事件的主要原因,但是如果有这一环节的控制,那么还是可以做到及时止损的。所以,互联网产品在追求高速迭代的时候,已经对质量有了妥协,就不要再对监控做妥协了,因为这已经是你的最后一条内裤了。

损失怎么办啊?**

对于这次漏洞,拼多多的损失是必然的。那么后续会怎么处理呢?对于公众,有群里截图说会砍单处理;对于员工,有职言上爆料相关部门年终奖泡汤。

先不论这些是不是事实,谈到这个问题的时候,让我联想到前段时间,东航票务系统Bug导致的白菜价机票事件,当时还有前同事有抢到非常廉价的票而晒了朋友圈。随后,东航当时的处理被誉为一次教科书式的危机公关,对于因Bug导致的机票全部有效,看看当时的报道:

东航的这个事件本身也是系统Bug所造成的,但是通过及时的危机公关,却大大提升了东航的知名度,打造“负责、担当”的品牌形象,效果甚至比专门做广告还要好,而这些付出的费用可能还远远低于品牌营销的广告!