拼多多技术事故复盘，程序员应该学到什么？

90後丶幸福传

                        作者 | 范学雷                        编辑 | 李佳                        每一次事故都是在倒逼技术团队成长，没有谁能保证不写 Bug 不出错，我们要做的，是在事故发生以后，找到问题的根源，及时填坑止损。        2019 年 1 月 20 日凌晨，有网友称拼多多出现重大 Bug，100 元无门槛券用户可以随便领取并进行消费。大家争相传播，大半夜的都起来领券，有的用户甚至领取了上千张。机灵的用户，以最快的速度花掉了优惠券，比如给中国移动充值。
拼多多凌晨回应，“有黑灰产团伙通过一个过期的优惠券漏洞盗取数千万元平台优惠券，进行不正当牟利。针对此行为，平台已第一时间修复漏洞，并正对涉事订单进行溯源追踪。同时我们已向公安机关报案，并将积极配合相关部门对涉事黑灰产团伙予以打击。”
随后，拼多多发言人表示，实际最终资产损失或低于千万人民币。
这个事情发生后，在技术圈炸开了锅，可能是源于传言的“一个 bug 可能给公司带来 200 亿的损失”。
作为程序员，我更关心的是，这个 bug 到底是怎么来的呢？根据市场传言，我们大致可以得到如下的一些线索。这些线索的真实性还有待考证，或许并不是这次事件的真实情况，但是这也不妨碍我们通过这些线索，来探讨一下这起事故给我们带来的启示。

• 好多人羊毛弄了几十万；
  
• 这张券是测试券；
  
• 系统在凌晨自动上线测试券；
  
• 运维发现系统爆了，超过了阈值；
  
• 当事人手动下线了测试券；
  
• 手动下线的测试券，早上八点又上线了。
  

这些端倪看起来可以合理地解释一个重大 bug 的部署和运维。从这些端倪中，除了优惠券本身的设计问题，我们也可以看到运维的混乱。测试券怎么能够上线呢？系统爆表了，为什么没有跟进风险防范措施？手动下线了的测试券，怎么又能够重新上线了？为什么上线、下线优惠券操作这么草率？如果一个软件系统是这样的运维水平，出问题是迟早的事情。如果还没出问题，只能说运气太好。
                优惠券的设计问题        第一个吸引我们的问题是，“好多人羊毛弄了几十万”。这就意味着，一个人可以领用上千张优惠券。好多人这么操作，说明无门槛券的领用，技术门槛极低。
一般的优惠券，类似于折扣券，都有使用门槛，比如买 100 优惠 20 元。无门槛券，顾名思义，就是没有使用门槛的优惠券，100 元的优惠券可以买 100 元的商品，几乎等同于现金。由于无门槛券类似于现金，它和一般的优惠券就有重大区别。
先不去管羊毛党，拼多多号称有 3 亿用户，如果每个用户都合法合理地领用 100 元无门槛券，这就需要 300 亿人民币。账户注册，几乎是零门槛，如果微信 10 亿用户合法合理地注册、领用无门槛券，给手机充个值，这就需要 1000 亿人民币。
截至昨日，拼多多市值接近 230 亿美元，折合人民币也就 1600 亿的样子。100 元无门槛券随便领，这看起来像是要拆了公司给大家发奖金的姿态。这肯定不是无门槛券的预期。
随便领的无门槛券，怎么看都不是一个合格的商业设计。最起码，定个数量上限吧，大家抢完就没了，几百万送就送了。送几百个亿，不符合正常的商业逻辑。
一般而言，即便是普通优惠券的领取都有很多附加的条件。比如说，一个账户只能领取一次，或者只有新账户可以领取。而账户的认证，也要有很多的安全措施，比如绑定手机号，绑定设备，使用安全连接等措施。账户的认证和管理，是一个服务网站最最基本的功夫。如果一个人可以领用上千张优惠券，那么账户管理的这个基本功，不能算及格。账户的管理水平如果不及格，这个网站的风险比我们想象得还要糟糕。
这么糟糕的账户管理，这么糟糕的商业设计，太出乎人的意料，不符合正常的逻辑。所以，我比较认同这只是一个测试券，不应该出现在正常运营的系统中。而如果真是测试券的问题，暴露的就是软件研发和运维的混乱。
                混乱的研发和运维        一个测试券，居然自动上线；手动下线后，又自动上线。这样的产品发布流程匪夷所思。一项功能的出炉，要经过设计、实现、评审、测试、审批，才能够走到正式的系统中。这些环节，只要有一个环节发挥了作用，测试券都不可能上线，更不可能自动上线。
上线后，还要有持续的风险监控。如果系统超过了阈值爆掉，运维能够第一时间获得爆表的信息，比如大半夜的，账户异常活跃或者优惠券业务火爆，也能够及时地截断这个风险。
由此可见，对运维人员的合理约束机制，是一个商业公司必须谨慎对待的问题。哪能随便一个测试券就可以直接跑到正式的系统中呢？软件的运维，是一个需要特别关注风险管控的环节，尤其是软件的质量没有跟上的时候。软件的运维事故，有时候甚至会颠覆一个行业。
2011 年，一个数字证书签发机构，给谷歌签发了多张数字证书。而谷歌从来没有向这个机构申请过数字证书。也就是说，数字证书的持有者并不是谷歌。这个持有者可以冒充谷歌的网站，盗取用户登录信息，包括用户名和密码。这意味着要么这个公司技术水准有问题（黑客攻击），要么这个公司的运维能力有问题（乱发证书）。这个安全问题在 2011 年 8 月份被曝光，几乎所有的软件巨头立即宣布封杀这家机构的数字证书。9 月份，这家有着很大市场影响力的机构就宣布破产了。
然而，这不是最终结局，数字证书签发行业的厄运才刚刚开始。人们好像忽然认识到，信息安全不能依赖数字证书机构，一个 4000 亿美元市值公司的安全，不能依赖一个 40 亿美元市值公司的运营能力。于是，各种各样的新技术在随后几年争相出现。这些新技术如果广泛使用，将彻底抹掉整个数字证书签发行业。这样的日子，离我们已经不远了。现在，数字证书签发机构的日子过得都比较惨淡，卖的卖，散的散。
频频发生安全事故的顺风车，从长期看，也具有类似的性质。相比之下，如果一次事故损失的只有钱，影响可能还算是可以勉强承受的。希望损失的只有钱，但是我对这个期望并不乐观。
追本溯源，运维如此混乱，一般和软件的质量脱不了干系。 一个正经的软件系统，该怎么出品、该怎么部署、该怎么运转、该怎么授权、危机该怎么处理，这些问题都要有设计、有实现、有预案。当事人设计了一个无门槛测试券，就可以在运营系统里跑，而且还可以无限领，这暴露的是背后烂透的软件质量，以及松散、无序的软件研发流程。我们常说，优秀的软件出自优秀的流程。混乱的研发流程，很难出品高质量的产品。
                我们该怎么做？        无知者无畏，安全问题之所以特殊，就在于它如果不发生，我们也许永远不知道问题的存在，当然也不知道问题有多严重。每一次安全危机，都不应该被浪费。如果我们是当事人，有哪些办法可以避免类似的事故呢？
最紧急的事情，就是赶快把账户安全的债给还了。要不然，经过这一次的传播，一大堆的眼睛看好了这块肥肉。黑客攻击的下一波，也许已经在路上了。
接下来，要尽快考虑下面的几件事情。
第一件要做的事情，就是规范研发流程。一流的软件研发流程下出品的产品，再差也不会差到哪儿去。在这个研发流程里，程序员不能单枪匹马地蛮干。需求要讨论，设计要预览，功能要审核，代码要评审，软件要测试，系统要试运营。人人都会犯错误，每一个环节，多几双眼睛盯着，就大幅度减少了犯错误的几率。程序员也能通过研发的流程快速成长，进一步降低错误发生的几率。一个好的制度，可以成就人；一个坏的制度，可以糟蹋人。
第二件要做的事情，代码的安全要重视起来。代码的安全，不都是指黑客入侵。这个无门槛券的领用，就是一个严重的安全事故。反映到代码层面，可能就是账户管理不安全，商业逻辑没有校验，运维授权管理散漫，异常风险没有及时预警。
第三件要做的事情，商业设计要预先推演。即使没有黑客黑产，1000 亿人民币无门槛优惠券，也不是任何一家商业机构愿意支付的成本。这是一个幼稚园水平的错误。 如果商业逻辑不成立，也就意味着有缺陷的软件需求。建立在漏洞百出的需求上的软件，也会是漏洞百出的。
第四件要做的事情，改进产品上线的机制。设置产品上线的检查点和流水线，任何一个检查点失效，流水线都要中断，产品都不能上线。这些检查点包括产品的试运营、功能的审批、配套的监控措施等等。
第五件要做的事情，提高运维的风险防范能力。一个有着 3 亿用户，230 亿美元市值，经营电子商务的公司，是黑客眼里的肥肉。尤其是用户隐私信息和现金流，关系到企业的生死存亡。这种体量的公司，具有优秀的风险防范能力是最基本的要求，而不是锦上添花的东西。风险的主动检测、及时预警、快速应对，这些措施都要跟得上。
如果无门槛券的商业设计经过推演，软件功能经过讨论，实现代码经过评审，上线经过预演，事故能够及时预警，只要其中的任何一个环节发挥了作用，这次事故都不会这么惨烈！
我理解一个公司不顾一切全速前进，以质量换速度的竞争压力和动力。只是，当我们追求眼下速度的时候，也要考虑三尺以外的未来。要不然，这屁股后面累积的债，真会成为怎么甩都甩不掉的大尾巴。
没出问题的时候，你永远也不知道代码质量有多重要。范学雷老师教你如何写出安全高效的代码，请关注极客时间《代码精进之路》专栏。

点个好看少个 bug