从PDD薅羊毛事件想到DevOps那些事

Test Ninja 软件质量报道 2019-01-21

如果不了解故事背景的,可以先看:

质量警钟:拼多多100无门槛券随便领,官方紧急下架


DevOps技术发达的今天,PDD薅羊毛事件本不应该发生。

  • 原本就不该出现这种无门槛的优惠券(等同于送钱),就算一定要发这张优惠券,应该发给特定用户目标群,不该让同一个人能薅几十万羊毛;

  • 即使业务需求没错,而是开发代码写错,测试也该发现;

  • 即使测试没发现,上线后半夜突然爆发的流量也该被系统运维监控到;

  • 即使系统运维监控不到,旁路实时资金风控系统也该检测到;

  • 即使这些没有监控到,是不是运维值班人员人肉也该发现,不至于9小时后才被制止。


这种业务需求的实现,不仅需要开发(Dev)按业务需求实现与验证,而且在运维(Ops)那边应该有相应的防范机制和技术保障措施的。而昨晚PDD薅羊毛事件显示PDD没有这样的验证、防范机制,所以羊毛党能直接用猫池+脚本API进行批量自动操作,薅羊毛才能薅得这么快、这么多。


这其实不是一个问题,而是显示PDD在研发、发布、运维和风控方面的一系列问题,如需求评审和系统业务测试不到位、系统CI/CD机制有漏洞、缺乏良好的业务风险校验或控制环节、运维监控形同虚设,甚至人工监控可能也缺失。


 1. 从需求上看

这种无门槛的百元优惠券就不应该出现!如果为了发展新用户,送无门槛优惠券也是电商常用方法,但应该经过公司某部门审批、在系统内有限制(单张不得高于30元,这叫内禀业务规则),而且还有其它业务条件,如一人只能领一张,而且不能应用于虚拟物品(如电话费、Q币等)的消费。如果没有这些限制,就自然给羊毛党有可乘之机,他们自然就购买那些最具流通性、实时交易、实时变现的虚拟产品(Q币、话费等),例如Q币实时充值、实时7折优惠售出,很容易变现,况且很多羊毛党都有专门的洗白通道。

这类需求错误,产品经理或业务人员就不应该犯,即使犯了,开发和测试对需求的评审、实现和验证过程中也该发现。


 2. 从研发上看

开发实现这类“无门槛的百元优惠券”用户故事时,也会想想哪类用户角色会使用这类优惠券,并在代码中加以限制。如果是开发失误了,测试会发现。测试用例都是有前置条件的,或测试人员进行手工测试,也往往需要扮演不同角色进行业务功能的测试,自然也能发现这类问题。

如果是测试人员配置错了测试券,就自动上线了,那说明持续集成/持续交付(CI/CD)缺乏自动验证,或者说缺少一个Staging环境(相当于Beta环境)来验证新上线的特性。即使直接上到产品线,也需要在部署完之后进行快速测试。即使没有做部署验证,如果采用灰度发布,即使出问题,影响范围小,造成的损失也不会这么大。


3. 从运维上看

即使需求或研发某个环节出错了,错误的特性也上线了,在运维端也应该被监控系统发现。如发现各种异常:

  • 在凌晨3点到6点时,系统有大量访问,流量快速上升…

  • 不同账号出现大量同一收货手机号、同一收货地址、同一行为、同一IP地址、同一支付ID等;

  • 某一虚拟商品被抢购,销量暴增;

  • 某一类优惠券的使用量在快速增加…

  • ……

这类异常数据或问题自然是不正常的事,会触发内部报警机制,运维人员在第一时间就能处理。但是这些监控策略或机制也没有,据说是研发人员上班看到并发异常的日志才发现的


4. 题外话

某公众号谈到PDD 研发和运维团队不乐意修内功,而喜欢秀外功,因为内功不容易被看到、不容易体现KPI,而外功容易,甚至很多运营恨不得管羊毛党叫爸爸,跪求他们来薅,反正羊毛薅完,GMV是特别好看,亏损是公司的,绩效奖金和升职加薪是自己的,所以何苦来哉?

从此想到软件测试。真正做好测试分析、测试设计的业务测试,其实对公司很有价值,但不容易讲故事、不容易写入KPI,在外面找好的工作机会还少。这样许多测试人喜欢搞自动化测试、重复造轮子,测试效果却一般,但这毕竟容易讲故事、容易写入KPI,即使成本很大,对公司不一定是好事,但对测试工程师是好事,既有好的绩效,又提高了自己的能力,出去找工作更有竞争力。

文章已于修改

    发送中

    本站仅按申请收录文章,版权归原作者所有
    如若侵权,请联系本站删除
    觉得不错,分享给更多人看到