从拼多多事件看DevOps质量门的重要性

最近，一则消息刷爆朋友圈：拼多多惨被撸羊毛，据说高到200亿！震惊，一夜之间，200个小目标就实现了？这究竟是道德的沦丧还是人性的扭曲？于是，多多拿起法律武器，誓死追回丢失的羊毛，结局尚未上演，吃瓜群众尚需耐心等待——

Why？ 造成这一切的原因是什么？作为一名IT程序猿，当然有必要探究一番。根据可靠的小道消息： 都是DevOps惹的祸。一个内部的测试功能结果被DevOps自动上线。DevOps，这锅你的背！

不管是否真假，这引发我们对DevOps效能的反思。DevOps作为实现产品快速研发、部署、发布、监控的利器，在业界已经越来越广泛的应用。能力越大，责任越大，当DevOps因为其先进的理念，高效的工具而越来越承担更多责任的时候，我们更需要对其投入更多的关注：因为它的一个疏失，将产生严重的后果。

其中，最重要的一点是安全。

高速的DevOps流水线以快速反馈作为核心内容，但其中一层一层的质量控制门是否完善则完全依赖各种质量门的建设。DevOps的质量门根据不同的产品可能各有不同，但基本包括如下内容：

UT单元测试

代码静态检查

ST系统测试

WEB系统扫描

系统漏洞扫描

系统灰度发布

系统业务监控

拼多多事件让我们需要深入思考各个质量门是否真的可以控制各种异常情况。我们以系统业务监控为例，拼多多是否对虚拟券的使用情况进行了监控？或者对手机充值、QQ充值这种业务进行监控？考虑到拼多多如此巨大的商品种类， 是否设置了如此细致的业务监控值得怀疑。进一步，假设拼多多设置了这些监控，这些监控告警触发的时候内部应该如何处理？处理的时间需要多长？当这个漏洞被传播的时候，可能每分钟都会给公司带来巨大的损失。但反过来，当业务告警触发时候，相关人员能不能及时意识到问题的严重性并且快速处理？这是对DevOps使用的极大考验。

我们也可以同步思考一下灰度发布体系对这个问题是否有帮组。灰度发布系统通过部分天使用户的使用来提前验证系统可能存在的问题。其核心价值一般在于验证新功能对用户是否产生效果。考虑该问题，根据新闻描述，并不是一个正常的功能。对大部分正常用户不一定可能触发，但当一个恶意用户发现以后，可以在极短的时间内传播并造成巨大的危害。从这个角度而言，基于统计度量的灰度发布对该类问题可能无效。

拼多多的事件类似于黑客攻击。让我们对比黑客和大部分产品的研发人员之间的区别，犹如杀人无数的专业杀手和纯洁小白羊的区别。黑客，以发现和利用产品漏洞作为自己的本质工作，工具专业和技术精湛。而研发人员，却常常犹如白莲花一样去理解这个世界。从不或者很少思考安全的问题。在他们的世界里面，排第一位的永远是进度。有一句格言激励着他们“完成比完美更重要！”。希望拼多多事件给他们以启示，了解到“安全”和“质量”是一个产品最本质的要求。没有了“安全”和“质量”，谈不上“完美”，也谈不上“完成”。因为创造的是一个“不健康”的产品。正如大部分人要认识这么一个现实：你家里重来没有进过贼不是因为社会上没有小偷这个职业，也不是因为你家的门防盗好，仅仅是因为你穷。所以穷的时候就要树立正确的安全观，有钱的时候更要买保险柜和防盗门。对很多企业来说，不能适应成长的转变，拼多多市值已经快超过京东了，依然出现这种问题就是一种警示。

DevOps是一种工具、一种流程、一种文化，但一切的一切，最后都依赖于人，当产品人员不建设它，在DevOps流水线上挂接各种锋利的武器，那么它不过是一件不华丽的摆设而已。