支付宝Bug后续分析，double check不能少

大家好，我是洋子，最近1.16下午2点发生支付宝的严重事故（支付订单享受国补8折）相信大家都听说了，事件后续支付宝官方明确表示不会对用户进行追款，真心有点酸了，下图为支付宝官方的回复

据内部消息称，本次支付宝补贴事故可以概括为：淘宝配置国补订单的规则，在测试的时候配置到了线上，影响到了支付宝，花呗等等支付场景。并且实际资损并没有达到亿级。只有1千万左右，并且还有1千多笔的主动退款。之所以定级不高，因为本次事故主要责任在淘宝。

最后定责为：资损由淘宝负责（p1），舆论由支付宝承担（p4，不知道后续还会不会升级）

业务背景：国补补贴（针对3C类商品）由淘宝垫资，后续政府结算给淘宝，淘宝使用支付宝平台进行活动配置。

故障初步原因：淘宝配置时将测试活动直接配置上线，导致目前在支付宝侧转账、支付、花呗还款等非预期场景出现国补

所以支付宝只是受到了牵连并不是问题的引入方，对于整个事件引发的原因猜想，我认为是（淘宝某运营）在支付宝某个常规营销活动后台配错了营销模板，把优惠额度和优惠金类型都写错了，一般这些后台都是由业务方的运营人员去操作

这里展开谈一点便于大家理解，为了操作方便，研发会将一些操作频繁且重复的步骤开发出一个可视化后台，可以理解成一些表单配置类似的，比如一个活动配置后台，配置好活动的时间，上传活动物料信息，玩法，生效时间和范围等，到了生效时间，线上用户就能直接刷到这个活动，从而不用每次活动涉及代码开发，节省RD人力

而操作这些后台的人员一般就是运营，公司为了节约成本，可能会招一些外包运营来操作配置后台，操作配置后台本质是高危操作，因为一旦运营操作失误是会直接影响线上用户，即使马上发现，下线活动可能也有所延迟，造成损失

说来也巧，洋子的所在的公司前段时间也发生了类似的严重事故，因为运营配置物料活动上线操作有误，导致app客户端产生1000w+次崩溃

• 误操作步骤：误将活动开始时间配置成过期的时间（如2025年的活动，配置成2024年就结束了），并且配置的物料也没有在上线前进行检查），导致修正活动开始时间后（线上开始生效）但物料仍有问题，引发崩溃
• 技术根因：物料中的图片资源字段为本地路径，非正常使用时的图片base64值，某组件先获取图片base64值，未获取到再从本地路径上找，但C端用户手机本地路径上未预置上该图片资源，导致无法正常获取，最终引发崩溃

对于一家互联网大厂，客户端发生崩溃带来的损失是巨大的，不仅是用户时长的损失，商业上也会带来资损

看起来这些案例case在互联网大厂都无法避免，更别说一些中小厂了，这些问题都是人为造成，而不是功能性的bug，显然不能甩锅给QA或者RD了

如何避免

我看很多文章提到了环境隔离，即在非生产环境（测试环境、预发布环境）下先进行先配置测试活动，在测试活动验证无误后，再在生产环境上进行配置，其实这一点我个人认为在后台在架构设计上一般已经考虑到了这一点

有了环境隔离并不能完全杜绝问题，除了技术手段上进行把握，还要在流程上引起重视，很多人觉得配置一个活动不是件大事，正是这种侥幸心理常常会引发问题，对线上要始终有敬畏的心理

• 上传物料/活动配置环节：后台增加物料或者信息填写报错机制，比如配置的活动已过期，物料的格式（包括读取路径等）或者生效范围过大需要有错误提醒
• 审核环节：除了运营自己，RD、QA、UI/UE等角色也要进行上线前的审核检查流程，有double check机制，在预发布环境确认线上效果
• 上线环节：采用灰度发布的形式，单台，单边实例上线完成有停留观察时间，无误后再继续上线
• 上线后监控：监控活动的异常情况及时感知和报警
• 应急回滚方案：提前制定好应急回滚方案，在出现问题时RD能快速定位问题并进行止损

这是我对此次事件的一些思考，大家如果有更好的思路可以在评论区留言