前支付宝工程师带你复盘支付宝P0故障

前支付宝工程师带你复盘支付宝P0故障

事故介绍

首先叠个甲，所有数据来自互联网公开数据，没有泄露任何老东家数据。

大家可能都听说了，但是我还是介绍一下。2025-1-16 14:40开始，一部分用户发现在支付宝内进行支付时，发现订单被优惠减免了20%的金额。意味着原本你买一个手抓饼可能100块，用支付宝直接省20。而且这不仅限于支付订单，转账订单也可以享受这个优惠(不知道有没有人开两个小号，反复转账薅羊毛的)。

支付宝方面很快反应，在14:45时完成了故障修复，并且在2025-1-17 1:00发出声明，称不会对享受到这个优惠的用户追回资金。(敢做敢认，点赞)

产生原因分析

在支付宝的通告里，我们看到，产生这个事故的原因是"某个常规营销活动后台配错了营模板"，这句话我给大家解释一下。一般一个新的活动功能的上线，可能需要程序员开发新的功能，然后将功能里需要使用的规则，做成配置，配置在营销中心的管理后台上。当然对于一些比较成熟的活动，也可以直接复用以前的代码，只需增加配置即可。

但是在通告里，我们没办法判断这是一个新开发的活动还是复用以前开发出的老活动。针对需要开发的新活动和可以直接使用配置复用的老活动，这两者我们单独分析。

需要开发的新活动

一般新活动开发完毕后，正常是程序员会提前告诉运营在配置中心建好规则，并且将灰度人群置为0。然后程序员发布新代码，发布中因为没有人群命中活动规则，所以活动不生效。为了验证代码有效，会在发布的早期，让运营在营销中心配置一些测试用户，来测试看能否命中规则，并且验证活动在后续的收单，结算流程里是否正常。

举一个实际的例子，程序员小薰在服务demo order service里开发了新功能，需要发布上线，demo order service假设有1000台机器，小薰联系运营小丽在运营中心配置几个灰度账号，用来验证在线上发布后功能是否正常。在灰度发布阶段，会先选择几台机器做灰度，一般不超过10台，比如

• 第一批次 3台
• 第二批次 7台
• 第三批次 5%
• 第四批次 10%
• 第五批次 20%
• 第六批次 35%
• 第七批次 全量发布剩下所有的机器

根据支付宝解决故障只花了5分钟，我们可以推测出，应该是在第一批次时就发现了问题，并且采取了止血措施。那么收到影响的流量就是0.3%-1%，大家可能好奇为什么能确定说肯定是在第一批次就收到的影响，因为实际一次服务重启很耗时，一般都不止5min，而且服务发布后会有10-30min的观察期，再结合发生事故到解决事故总共没花费5min，我们可以推测出，第二批次应该还没发布。

但是流量并不代表受到影响的支付单量，因为要考虑有多少人命中了这个规则，这就取决于运营的配置了，如果运营只是把一些不应该开灰的用户加在了白名单里，影响还好，只会有一些固定的人员受影响。但如果运营是直接100%用户全量灰度，那就糟糕了。

我们得出在这种情况下，受到影响的单量范围为(0, 1%)

亏了多少钱

相信大家最感兴趣的一定是这次事故支付宝到底亏了多少钱，要回答这个问题我们首先要知道支付宝一天的交易流水是多少。当然这种数据官方一般是不会放出来的。但是我们可以大概算一下

23年移动支付555万亿，增速为11%。我们假设还是按照这个增速来预测24年的移动支付，当然还要考虑支付宝和微信在移动支付交易市场的份额，大概6/4开的比例。

那么24年的移动支付交易额

#以下单位亿元
5550000 * 1.11 = 6160500
#那么24年的平均日交易额
6160500/365 = 16878.08
#考虑到昨天事故发生的时间已经是25年，我们直接用24年的平均日支付交易额不合适，我们假设移动支付的日交易流水增长是线性的，我们再乘以一个增长速率得到12月的移动支付日交易额
16878.08 * 1.22 = 20561.26
#再乘以支付宝再移动支付市场的份额
20561.26 * 0.6 = 12336.76

那么我们假设支付宝一天的交易金额12336.76亿元，那么结合我们预估的影响流量范围(0, 1%)，以及每一单20%的优惠力度，影响的时间5min，得出在事故事件内受影响的订单数量

# 单位亿元
12336.76 * 0.01 * 0.2 * 5 / 60 / 24 = 0.0857 

即亏损金额不超过857W，实际上考虑到这种带有优惠的活动可能会有用户薅羊毛，重复下单，我们可以再把它影响范围乘以一个放大系数，比如1.5，即

#单位万元
857 * 1.5 = 1286

可以看到金额顶天也不会超过1286W，而且在实际的营销活动里配置的时候，一个营销活动的预算金额是会有上限的我们称为资金池，超过这个上限即使参加活动也不能享受到优惠，这个金额我们假设为2000W(一般活动不会这么多，一般几百万就算多了)。如果资金池小于1286W，比如资金池只有500W，资损的上限就只有500W了。

总的来说，我们还是认为本次事故的资损对于支付宝来说并不算多，大概1286W。

那些人会背锅

大家第二感兴趣的肯定就是那些人会背锅了，我们可以从整个流程上看那些人参与了这次事故。

• 运营 作为直接引发本次事故的责任人，没有认真检查配置，就上线，肯定要背大锅，主要责任跑不掉。(考虑到蚂蚁最近的降本增效，不知道这位运营是不是本部的也说不准)
• 开发功能的程序员 开发功能的程序员负责上线服务，并且把配置设计好交给运营人员去配置，虽然不是程序员配的，但是作为服务的owner，理论上应该要再发布前再去确认一下这个配置正不正确,所以开发跑不了(是不是感觉pua太凶了，放心吧，实际老板找你北固时说辞肯定比这更严重)
• 运营的老板，以及审核了运营配置的老板 所有配置都需要老板审核才能生效的，虽然老板一般不细看，但是不出事都好，出了事，背锅吧。
• 测试 测试老实说，责任不大，一般这种时候就是拉出来做替罪羊，和开发一样要带点连带责任。
• 程序员的老板 老板这种时候就还是连带责任
• 两位老板的顶头上司 这种级别的老板一般就是P9/P10了，分团队。责任大小也看事故的影响面，影响不大的话，处分大概就是罚酒三杯，大的话，被一撸到底边缘化也有可能

不需要开发的老活动

如果是不需要开发的老活动，运营直接在运营中心改配置即可让活动生效，这种情况下受到影响的流量范围就取决于运营的操作了，(0,100%]都有可能

亏了多少钱

这种情况下资损的计算方式还是类似上面，只不过在流量的影响范围变大了，我们可以直接用上面计算出的亏损金额乘以流量的影响倍率

#单位万元
1286 * 100 = 128600

看起来好像很夸张128600，以下干到13Y了，但是还是像我们上面说的，资损不会超过资金池配额，我们假设的资金池配额5000W，所以其实还好。实际的资金池配额我想会远远低于这个数。

那些人会背锅

• 运营
• 运营的老板
• 运营的老板的老板

背锅原因同上，不细说了

事故总结

从这次的事故，我们可以复盘一下再新功能上线时需要面临哪些问题以及对应的解决思路。当然支付宝内部也都有这些手段的成熟解决方案，但是实际落在执行上却是稀巴烂。

1. 功能开发时要做好监控，能够监控出功能异常的流量并及时报警(本次事故的表现里得满分)
2. 做好发布前的配置检查，配置上线一定要有审批，开发要和实际的配置操作人确认，这里的确认不仅仅是口头确认，要自己心里有数(本次事故得0分)
3. 发布前要做好降级预案，必须要保证当功能出现异常时能降级(本次事故表现满分)