一个错误的测试流程，PDD可能挺不过去了
今早的朋友圈被一张截图刷屏了，200亿的羊毛被薅，不知道PDD顶得住不！
根据微博的内容我们可以看到问题是这样的，一张“神券”满100-100的无门槛券，不限量的被用户领到了，然后通过领券去B端商户做自动充值，实现了套现。
其实这不是第一次出现的重大生产事故，在2017年12月盒马也出现过同样的问题"无门槛满100-100"神券，还好刹车够快！云层也就薅了2000￥左右，胆子小还有2w的券就烂尾了，据说盒马被薅300多万。
所谓外行看热闹，内行看门道，这次闹大了到底是什么原因呢？是测试的锅么？大家都在说的回档又是否可行呢？
首先生产环境的这类问题一般都是因为测试或者特性开关错误导致的，如果非要明确来说，大多数都是持续部署没有完全自动化或者完全自动化的脚本没有有效测试导致的。
在预测试环境上一般都会有生产的1:1部署，在DevOps下会通过持续发布的特性开关预上线部分功能，比如“神券”。但是这个接口或者数据是不可能被普通用户访问到的，也就是数据隔离或者特性开关要做的事情。自动化的脚本哗啦一下就上去了，确实执行的很快，所以如果错，那么就错的更快，回头都来不及。
其次出现了这样的问题，按道理很快就在监控上发现了。这里涉及到另外的问题，是直接同步金额交易还是代扣异步交易。云层根据自己的猜测，如果选择哪种下单后等待商家确认发货的长流程，那么券是用了，但是只要商家没发货，PDD又不给商家结算，最后肯定会被砍单的，作为结算和风控系统会监控的。而薅羊毛的人肯定懂的，我必须要选择快速套现结算的方式，自动下单冲话费就是同步自动化的最佳方式。由于是自动化的下单充值的，这块的结算“也许”是异步的，也就是商家自己先垫钱发货给买家，而PDD周期性结算给商家（有点像支付宝余额提现一样的概念），而某些商家设置的自动发货数量不设置上限，并且也有担保甚至较大透支额度，导致一晚上醒来2000条手机扣费短信，最后一条是提示信用卡欠费了！这个损失PDD会负责么？我不好说。
最后出了问题回滚？这不是游戏的数据可以直接回档的。举个例子：盒马券出来了，如果这个券还没用，那么没问题只是我数据库的一条记录，但是一旦下单了，这个单就到了发货平台了。发货平台是自动构建快递内容的，你可以说单无效，但是货已经发出去了，难道你还能收回来么？而且强行作废单据可能会导致整个系统的瘫痪（脏数据），这个损失谁能接受。作为当前互联网电商，起飞是很容易的，但是在天上发现轮胎出问题了要在天上换轮胎，远比我们想的复杂的多。
（有种你下来，有种你上来）
朋友圈有不少朋友也发表了自己的见解，我们毕竟不是PDD内部的人，也无法完全复盘或者在外BB看热闹。云层觉得这样的事情以后也不会杜绝，每一次事故的背后都有各种匪夷所思的疏忽也带来了对应内建质量的思考和优化。大家都会说这是没做好测试的问题，但是事实并不是测试就能Hold得住的，真的测试就能避免这个问题么？
未来测试也许是个最坏的时代，也许也是个最好的时代！
欢迎留言发表您意见！有奖哦！
精益技术 赋能过程