安全测试干货分享｜支付宝大促如何保障资金安全

2022-09-13 17:12:34random

random

订阅者

关注

10532
文章

0
评论

测试交流评论164字数 5302阅读17分40秒阅读模式

对于有大量资金流转的业务场景，如何保障相关业务的资金安全风险，是一个很重要的课题。在大促的场景下，资金安全保障更加挑战。

蚂蚁集团高级研发工程师夜飏为大家分享蚂蚁集团资金安全防控能力建设，并针对大促场景的特点，重点介绍大促场景下的资金安全保障方案，包括极速离线核对、智能核对防控、端到端防控等能力，希望给大家在资金安全风险保障上提供一些参考。文章源自玩技e族-https://www.playezu.com/239606.html

夜飏高级研发工程师
主要负责支付宝商家开放域和支付宝常态化大促的资金安全防控工作，先后负责过交易支付域、商家物料、营销域等域的业务风险防控。研究领域：资金安全，风险防控架构设计和研发，大促资金安全保障，智能资金防控产品化，资金安全研发效能等。2017 年加入蚂蚁集团，深耕在业务技术风险领域，从事研发和技术方案架构设计工作。文章源自玩技e族-https://www.playezu.com/239606.html

以下内容根据夜飏老师在TesterHome 社区与支付宝质量技术主办的测试之美《支付宝活动保障 - 资金安全》主题技术沙龙直播现场所讲内容进行精简整理，大约 5300 字左右。文章源自玩技e族-https://www.playezu.com/239606.html

一、资金安全保障相关介绍

蚂蚁集团提供金融支付等服务，资金流转量非常大，任何失误都会引发直接或间接等资金损失。文章源自玩技e族-https://www.playezu.com/239606.html

资金安全保障具体要做什么，我们在整个业务项目的全生命周期里，会引入多种资金安全风险分析和控制的手段，能够做到预防资金故障或者控制资金故障的一个影响范围，来减少整体的影响面。文章源自玩技e族-https://www.playezu.com/239606.html

文章源自玩技e族-https://www.playezu.com/239606.html

资金安全保障具体要怎么做，从三个方面来展开：文章源自玩技e族-https://www.playezu.com/239606.html

第一，机制流程建设

所有的项目在立项的时候，其实都会有资金安全的同学来介入，那我们会对这个项目进行一个资金安全风险的一个评定，比如说这个项目是高风险的还是无风险或者低风险的，对应不同的风险等级我们会有不一样的资金安全的投入的阵型。文章源自玩技e族-https://www.playezu.com/239606.html

在评定之后，我们在产品架构的设计上就会开始融入风险设计。比如怎么做到整体数据的全局一致性和全局幂等，那怎么能保证里面不出资金的一些风险，这是设计上面的一个考虑。文章源自玩技e族-https://www.playezu.com/239606.html

我们会在具体项目的系分还有研发，包括上线的阶段，会产出一个资金安全风险的系分，那这里可能会对整体的每个应用或者是链路之间，作为一个具体的资金风险点的分析。比如业务型的一些风险，或者其他风险，那产出对应的一些风险点，我们的防控手段，那在基于我们的一些资金风险系分的一个产出之后，我们会根据系分，做一些资金风险的一个防控规则的布防。文章源自玩技e族-https://www.playezu.com/239606.html

包括比如说实时的核对或者是一些监控，或者是一些紧急的预案等等，那在后续在项目真真正上线了之后，那我们就可能要密切关注于资金安全风险的一些执行的情况，一旦出现了报警或者是预期外的一些事情，我们要做第一时间的响应。包括后面的资金的应急，怎么减少资金的影响面，那这是机制流程方面。

第二，人员阵型建设

在我们的人员阵型建设上面，我们有 4 个层次：

1.在整体的架构设计上面，我们会有考虑怎么融入风险设计；

2.在研发同学的时候，比如设计或者是真正编码的时候，就要考虑到怎么做到资金安全的防御性的代码编辑。

3.质量同学在交付的时候，会有一个质量的验证和验收，那这里也会关注资金安全的一部分内容；

4.SRE 同学。那我们刚才说的，就是会产出一些资金风险的系分，然后同时做一些资金安全的风险的布防，包括后面的应急等等一些动作，包括复盘等动作，通过这 4 道防线来构筑我们的资金安全保障的阵型。

第三，多体系防控

我们会通过实时免疫的核对防控体系，还有一个近实时的免疫 + 的防控体系，以及基于离线的离线核对巡检防控体系，最后还会有一个免疫演练支撑平台，用这个平台来进行防控规则能力的有效性验证。

资金安全保障案例

举例来说，拿一个产品的交易支付链路为例。

首先会有运营同学在内部的商品平台配置上线商品，这里就会涉及到有没有可能出现配置问题，从而带来错配、漏配等配置型的风险，这都会带来一些资金相关的风险。

在商品配置完成之后，用户会进行下单购买，这个环节首先会在交易平台进行交易下单，这时候就会查询交易平台信息，进行判断预算（商品量）是否足够并进入到支付平台。

这时候如果是用支付宝的余额进行购买的话，就可能涉及到账务平台的资金流转，包括转账这样一个动作，从交易平台到支付平台再到账户平台，涉及的 3 个系统是不是就会存在上下游的系统一致性的风险，包括金额是否是全部相等，交易状态如何等等，这些都会带来资金安全风险，这些不同的风险我们都有不同的防控手段。

资金安全防控体系

之前也提到过，我们会有一些离线的巡检，包括实时防控体系和近实时的一个防控体系。可能外部的同学接触也比较多，基于离线的数据做一些比如 SQL 的防控，或者 SQL 脚本的执行，那这里重点讲一下我们内部的实时防控体系和近实时防控体系。

从业务系统出发，业务系统的订单单据到达终态之后，或者到达一定关键的阶段之后，会有业务执行消息发出来，然后我们这边可以通过业务插桩的形式主动获取业务订单或者相关数据的流转情况，通过 RPC 做到同步或异步触发，RPC 的触发请求还有消息的实时监听，都会到达我们的实时核对统一门面，由这个统一门面同步的路由分发到各个域的实时防控平台。

比如可能 A 域、B 域每个域都会有自己的特性化、定制化的防控，然后再完成防控规则的执行，这里可能还会依赖于其他的一些上下游的关联业务，比如交易支付就会拿到交易数据和支付数据做整体的一个风险模型组件，规则执行完成之后，那一方面我们会向资金风险事件平台进行一个上报异常，另一方面如果我们设置的是同步模式的话也会同步返回，做一个同步的风险拦截，相当于是能够做到一个事中的拦截的业务效果。

第二块就是以我们的近实时免疫 + 的防控体系，我们更多的是通过在线 DB 的数据的日志做到数据异步回放，把所有的线上数据统一聚合，做一个数据的缓存，我们这边会对全站数据做一定时间内的缓存，同时根据我们在每一家平台上配置的风险模型、相关规则，对数据进行组装，组装成一个风险模型之后，分钟级的能够触发规则的执行，那这里规则的执行脚本就是我们自己安全防控的同学在上面编辑的一些防控脚本。执行完成后，如果发生不符合预期的情况，我们也会有上报异常到风险事件平台。

二、大促活动怎样进行资金安全保障

大促有几个特点，第一个是参与用户比日常活动会多很多，玩法链路更加丰富，就会带来海量的数据；第二个是我们大促活动会有大量秒杀、发奖等场景，比如抢消费券、集五福等等，可能大家都玩过，这就会带来峰值非常高多特点。这两个场景特点，在资金安全上会给我们带来挑战，那就是怎么能够做到海量数据的统计防控能够达到比较高的时效性要求。

另外一个特点，就是链路上下游可能涉及到 10 多个系统，整体链路非常长，涉及的玩法更多，所以风险内容更多，带给我们的风险属性是非常多、防控研发成本高。

那我们怎么能够做到风险覆盖的齐全，同时能够降低防控研发的成本，大概有几套防控方案：

第一，大促极速离线核对

极速离线核对能够承接高峰值写入的场景，海量数据防控的场景，我们会通过 DB 的写入再到 Binlog 同步到数据的一个实时采集，再到数据的实时计算，最后会实时写入到内部的一个统一存储平台。

数据写入之后，我们会基于极速巡检平台、极速脚本执行平台，定时调度或者手动触发，然后用 SPARK 来进行相关的脚本执行，做到我们的资金防控。

通过这个方案，我们能够做到整体的防控时效小于 6 分钟，包括数据同步、规则执行，有了这样一个支持海量数据的高时效性的防控能力，我们就可以真正支撑大促。

第二，智能核对防控

之前更多的都是 SRE 或者质量同学人肉分析对应存在的一些风险点，比如上下游的一致性、金额计算等等，这些都是依赖于人的专家经验，那基于人的话可能就会存在一些人工分析风险点不够齐全等问题，另外人工参与成本也是相对比较高的。

基于此，我们建设了一个智能核对防控体系，整体的流程用户只需要配置一个风险模型来指定不同的上下游数据的关联关系，相当于是建立一个风险模型。建立好模型之后我们能够沉淀出历史数据，有了数据我们就可以借助算法来做到自动分析风险点，同时自动生成防控规则，做到规则的推导以及智能规则的孵化。

在孵化完成之后，用户只要简单的做一个评估，简单的一键的发布，规则就能正式运行。后续的话，我们就要关注规则运行的一些报警和其他异常情况，这时候我们就会反过来重新对规则进行重新评估，对算法进行进一步迭代升级。

我们还会有一个风险覆盖的统计报表，能够来揭示算法风险识别的准确度和覆盖度，进而推动算法升级，帮助我们减少很多人力分析的成本和防控的成本。

第三，端到端防控

传统的保障方案，要做到上下游数据全链路的正确性防控，或者一致性防控，可能涉及到 ABCD 等 10 多个应用，成本高。

为此我们提出了一些端到端的防控，比如在一些关键的节点，比如说首尾节点，把两边的数据拿过来，做到一致性的风险防控和业务的风险防控，那相当于中间的一些系统数据我们就可以简单忽略掉，这样就能覆盖全链路多个系统之间的关键风险，减少我们的防控工作量，而且任何中间系统导致的风险问题或者是异常数据，其实我们都能靠得住。

总结和未来展望

未来，资金安全的保障，我们重点关注 4 个模块：

风险分析——目前我们主要还是基于专家经验，后续我们这边会做一个基于数据血染，做到自动的风险分析。
风险研发——我们现在沉淀了诸如智能核对、端道端防控、极速离线核对、实时防控等方案，后续所有的基础风险，我们都会通过智能核对做到全托管，基本不用人的参与；针对相对复杂的一些玩法的风险，会做成模板化的规则，做到全复用。
规则验证——目前我们有一个免疫的演练平台来支撑风险注入演练，但是目前还是比较依赖人工，后续我们会通过风险的挖掘，让算法基于规则自动挖掘风险点以及一些对应的风险属性，做到自动的演练注入，帮我们发现对应的规则有效性验证。
防控保鲜——目前我们都是需要依赖线上的真实流量进行规则的保鲜验证，相对一些小流量场景可能不是那么的实用。我们后续会基于流量巡检，来自动构造一些小流量的场景来做规则的保鲜，减少防控的保鲜漏洞。

问答时间

我们交易平台和支付平台的数据的实时一致性，这个怎么做好检验呢？

夜飏：实时的一致性，我这里的话有两个防控体系其实可以说出来，比如交易平台如果交易完成之后，我们有两种方式，一种是业务插桩，就是我们主动会在业务代码里面插一个点，然后来通过 RPC 触发到我们的一个防控的平台，触发一个请求到我们防控平台，或者是通过交易成功的消息我们能够监听到，然后触发我们的防控平台，我们这边可以拿到了交易的数据，然后会通过 RPC 的一个查询数据，这样我有两边的数据，能够做到一致性的一个防控。

另外一个方案可能是比较重点，我们就还会有一个近实时的一个防控体系，基于线上的数据，比如交易平台会有交易表的 DB 数据，那支付平台也会有支付单的数据，两边的数据我们会配成一个模型，可以写一些规则的执行脚本，这个防控是能够做到分钟级的一个防控，所以也是能够做到近实时的一个防控能力。

各种各样的大促活动，会有很多核对规则，那这种都是通过人工来编写的吗？

夜飏：我们现在有两种方式，首先还是以专家经验为主的，可能关键的一些业务、比较复杂的一些风险点，可能还是基于人工去部署，比如实时规则、近实时的规则、离线巡检的规则。

另外像一些通用性的，比如上下游的一致性，我们现在是全部都可以托管给算法，用算法来帮我们去推导出对应的防控规则。

那其实要用户要做的就是说，我配置好模型，那我然后就是算法推到出规则之后，做一个规则的简单评估，就可以一键发布了。发布完之后，只要看一下规则有没有报警就可以了，这一块就基本很少人工去介入了。

测试同学和业务同学，他们的分工是什么样子的？

夜飏：我们这边会有阵形的一个概念，可以理解为我们有几道防线。在研发这边，可能更多的是关注于在代码设计上面，怎么做到一个防御性的一个代码的设计和编写；质量的话，更多的是关注到比如说产品功能验收或者前端的展示效果是否 OK；那 SRE 同学可能会更多的来承载资金安全相关的一些保障的内容。

当然这个肯定不是由我们一方完全能够完成的，比如其中有些风险的分析可能由研发质量一起参与到里面，甚至在大促的场景下面，我们基本的规则的一些布防全部都是由 SRE 团队来主要负责。在日常的低风险的一些项目，可能质量同学也会承担一部分的资金安全的一些分析，还有资金安全的一些规则的布防，那也会有 SRE 同学跟他们一起协同来做这样一个事情。

一个比较技术性的问题，前面架构讲到了用影子链路去做对账，那这个数据的持续性是怎么保证的呢？

夜飏：数据的持续性，我们这边一般都是会关注到一些终态，然后在终态的时候，会触发我们的防控规则，如果可能要关注到一些中间态的话，会基于一些特定的状态，比如所有的数据的可能是会有一些状态的流转，有状态机，我们会根据这个做区分和路由。

因为很多系统在现在分布式的体系下面，可能很多都是会保证最终一致性，比如交易到支付，交易成功交易掉支付，那支付可能成功了，但是返回交易的时候是失败，这个时候那可能交易会不停的发起重试，在 n 次重试之后，达到整个链路的最终的一致性。

我们的核对的时候，其实就要考虑这样一个状态，比如第一次交易状态没有推进，但支付已经是成功，那我们会有个实时核对来去校验，我们会把这一部分逻辑也兼容掉，那就是支付如果成功那我们会去查交易，看一下交易是否推进到已经终态了，如果没有，我们的防控能力也会支持重试的一个节奏。我们可能也会隔 10 分钟或者是隔 5 分钟，然后做起一次重试，那如果有些场景一致性不一致的情况频率非常的高，那我们可能也会同时铺设离线的核对，因为离线的核对的时效性可能是在小时级，那小时级的话可以理解为所有的数据基本都已经达到最终一致性了，所以这一块的话相对是就是误报，或者是我们这边所说的噪音会相对会更小一些。