支付宝的 P0 级事故，真的错过了几个亿？

支付宝 16 号下午出了一个 P0 级别的线上事故，5 分钟内的支付订单全部打 8 折，也包括转账在内。

也就是说，你给朋友转 10000 元，实际上只需要支付 8000 元，但你朋友还是能收到 10000 元。

显然，这很离谱。

所谓 P0 级事故，是互联网产品中定性最严重的问题，需要立刻马上修复。

事后根据支付宝官方的说明，事故原因是在后台配置运营活动时写错了类型和金额。

至于损失，支付宝说不会追回。

很多网友说，新年第一个红包是支付宝发的。也有网友说，感觉错过了几个亿。

对于这件事，背后倒是有两个问题值得讨论。

第一，支付宝在这次 P0 级事故中到底损失了多少钱？

第二，导致这次严重事故的根本原因到底是什么？

先说第一个问题。

我看到网上有很多分析，有说损失几千万的，有说损失上亿的，还有说损失 10 到 20 亿的。

其中，有人通过 AI 分析的方式得出了一个逻辑。

比如，2023 年第三季度支付宝的交易量是 118.19 万亿，平均到 Q3 的 92 天时间里，每分钟交易量是 9 亿元。

事故持续 5 分钟，按照每笔订单 20% 的折扣损失来计算，累计损失金额是 9 到 10 亿区间。如果算到今年的业务增量，估计在 20 亿区间。

那么，这种算法靠谱么？

我觉得是不靠谱的，因为这里面忽略了一个上限条件，就是补贴的额度设置。

在正常的产品设计逻辑中，涉及到这种折扣优惠时都会添加一个设置，那就是金额上限。

比如，优惠券数量和金额设置，对应就有一个数值上限。如果消耗额度达到这个值，就会自动停止。

如果支付宝的产品经理真的蠢到这个都没设置，那活该亏死，但我觉得可能性不大。

此外，国补本身也是有限额的，更何况支付宝只是所有支付渠道的其中一个，它不会把额度拉满。

真实的损失额度，我觉得在 8 位数的数量级是比较可能的。当然，这也是猜测。

再说第二个问题，事故原因是什么？

如果复盘这个事故流程，其中包含了产品、技术、测试、运营、审核等至少五个环节。

产品基于业务需求设计逻辑，技术根据需求完成开发，测试根据需求进行检测，运营上线后使用，对应负责人层层审批。

根据现象说问题，光是转账可使用补贴这一点，就说明系统本身的逻辑设计是有问题的。

然后是运营配置出错，既然能成功设置上线，说明系统本身就是支持的，这是个漏洞，也没有触发任何风控警告。

从实际场景来说，优惠的使用是有限制条件的，这既需要在产品需求里定义清楚，也需要在开发过程中做好判断，同时在测试环节也需要用例覆盖。

国补优惠在没有任何限制的情况下在转账、还款、商家支付场景下使用，这是个漏洞。

再就是上线前的覆盖测试，这种涉及金额的需求没经 过全量测试就上线，本身也不符合规范。

我是做技术出身的，我知道很多分支逻辑在主流程开发中可能会被忽略，甚至上线后才能发现问题。

即便是做到开发前的需求澄清和上线前的测试覆盖，要做到全场景无死角问题避免也是很难的。

所以，这就是系统开发过程中的不确定性。

另外就是审核，审核是一个人工流程，但凡是人参与的环节就会出错，这也是无法完全避免的。

支付宝的这个事故原因显然是两方面的，系统漏洞加人工失职。

类似的问题在很多互联网产品上都出现过，哪怕是一些超级大厂的产品，每隔一段时间我们都能看到类似新闻。

因此，人治情况下的产品就有这个弊端，如果未来 AI 能在这方面做好提前干预和及时止损，情况或许会变好。

对于互联网产品来说，机制要好于流程。

最后，支付宝在事后的公关表现上还是比较聪明的。

因为，用户需要的是 安全感 。

推荐阅读：《 微信重大更新，「蓝包」功能来了！ 》