资损防控体系介绍

shixinzhang 发布于2019-06-21 16:51 / 1730人阅读

摘要：建立后台触发熔断操作入口，人工录入熔断配置或资损防控检测出异常新增并生效熔断配置，应急情况生效熔断，日常支付链路不会过熔断判断。确认无误或故障处理完成后，触发解熔断操作，业务继续处理或驳回。

1. 资损盲区

随着有赞支付体量的增大，资产部门承担的资金管理，风险把控的责任也越大。我们一方面要小步快跑，快速支撑业务，又要稳住底盘，守好底线。支付业务底线就是守护用户的每一分钱，不能有资金损失。在我们搭建这套体系前，有赞支付资金类的线上监控是个盲区，缺乏自我发现的能力。业务成功了，但内部对用户的资金操作可能是错误的，导致资损。而且故障发生到发现的时间很长，且大部分是用户上报，导致故障的影响面扩大，用户的信任度降低。
预防资损有很多种手段，除了事前线下通过各种测试手段保障资金安全外，线上也是非常重要的一环。除了发现问题，相应的，出现故障时，资损止血的能力也需要配套跟上。

举一个最基本的支付业务场景，在有赞内部会经历以下几个系统之间的交互：

通过上图可以看出每个系统的处理结果，会依据系统建立的模型存储在数据库中，部分关键信息会传输给下层系统。系统之间处理的重要信息如金额、账户不一致就会导致资损。目前我们也内部对账会发现这些问题，但是内部对账都是每天跑批执行一次。如果依靠内部对账来发现这个问题，资损早就发生了。需要调用很大的人力物力去追款，大部分情况下还追不回来。我们分析了有赞近一年来的资损场景，结合历史的经验，总结出资损类故障发生有几下几大类:
1）有正确的输入，错误的输出：比如系统与系统之间的金额存储单位不一致，或者自己处理金额正确，传输给下游的金额错误，导致后面交易金额错误；
2）上下游系统的数据不一致：该处理的没处理，该到达终态的单据没有到达终态；
3）幂等控制失效，多扣款或多入账；
4）系统内部逻辑错误，无对外输出；
5）人工修复异常场景，产生资损。

2. 资损体系的诞生

基于解决以上问题的目的，我们设计了实时防控资损体系。总体设计思路围绕以下几点：
1）发现问题的实时性，减少故障的影响面；
2）信息流一致性两两比对、资金流平衡型检查；
3）全方位监控：业务触发、人工变更资金检测、历史数据检测；
4）检测的准确性，无误报；
5）和支付链路解藕，不影响主链路。

平台能力是基础，检测规则是其灵魂。基于对业务的丰富经验，我们可以沉淀一些业务资金规则，从旁路来约束和检测系统逻辑的正确性。比如支付金额-退款金额应该==结算金额，退款金额不能大于支付金额，凭证支付、现金支付无资金流类型不用调用账务，支付和账务之间会经过结算的处理，账务累计出入金额和支付的金额应该要相等。

3. 系统设计： 3.1 总体设计的架构图如下：

系统定位于事前线下测试环境兜底，事中一致性检测，事后资金兜底，不对业务造成入侵，完全旁路运行。触发点有 2 个，业务事件消息和数据库变更 binlog 信息。

分三类信息处理：
1) 基于各个业务事件比如支付完成事件、退款完成事件、确认收货时结算完成事件，账务收支明细变更事件等，触发运行系统内配置的依赖此事件的规则；
2) 通过监听 binlog 变更，可以检测到人为操作类变更, 按定义好的逻辑生成对应的检查点，每个检查点有包含多个链路检测。触发对应的规则运行检测全链路数据的一致性、资金的平衡性；
3) 人工处理历史数据前，对历史数据的质量进行前置检测。保证不产生二次资损。
通过系统间两两核对数据一致性，或者抽象出系统内的业务规则、资金规则旁路自检来发现故障。并且实时获取数据，实时运行，对于业务处理上有滞后和缓冲的场景，我们提供了异步运行的机制，以及三次重试的机会。全面提供系统整体的容错性，无因系统设计问题导致的误报。

3.2 处理流程图如下：

经过系统的沉淀之后，我们将过程中的数据存储到了 hbase，把整个支付过程落地成了可视化试图，可清晰的查看每个环节的数据形态,具体数据就不展示了。
比如一笔订单可以看到，当前已经是退款完成状态，对应的支付成功时支付、结算、计费、账务数据形态：

退款完成环节支付、结算、计费、账务数据形态：

3.3 资金熔断：

熔断的处理流程图如下：

基于我们之前建立的异常发现能力，同时我们需要具备资金止损能力。建立后台触发熔断操作入口，人工录入熔断配置或资损防控检测出异常新增并生效熔断配置，应急情况生效熔断，日常支付链路不会过熔断判断。
熔断支持按业务码纬度、指定的单号、商户号熔断；
目前我们在业务方接入的熔断埋点有 3 个点：退款、结算、出金。为什么考虑这三个地方埋点呢？
1) 我们整个系统的定位都是不侵入主链路，对用户无感知的，所以支付环节不考虑埋点。且钱不能流出有赞的体系外，一旦流出则无法追回。
2) 在支付链路产生的故障，考虑在退款、结算环节来做拦截，且支付完成后，钱停留在有赞的中间户，此时订正支付链路数据，对商户来说无感知。
3) 一旦在结算环节出现问题，则考虑最后一道兜底，出金报送银联前进行拦截。
确认无误或故障处理完成后，触发解熔断操作，业务继续处理或驳回。

4. 总结

建立了这一整套体系后，半年时间内，我们已经在线下环境联调时就成功兜底资金处理 bug，线上也避免了多起问题。并定期的进行故障演练来检测平台能力。
本文主要介绍大体的设计和实现思路，后续会有详细的技术细节介绍，敬请期待。资损防控路漫漫，共勉。

GPU云服务器云服务器短信防控防控风险防控-滑动验证码服务百胜防控防病测温一体机

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/11436.html

2016 钱盾安全报告（8月版）

摘要：信息泄漏严重，诈骗金额一路上升年至年上半年，根据钱盾监控的案件数据表明，单次诈骗金额逐月上涨，从元上涨到元，上涨。详细版钱盾安全报告版，请点击这里下载下载地址一、摘要近年来电信诈骗案件频发，从2011年至2015年，全国电信诈骗案件数量从10万件飙升至约60万件。而在今年，电信诈骗的数量依然在上升，政府部门在各种公开场合强调必须依法严厉打击，减少其对人民群众财产安全和合法权益的损害...

RichardXG 2019-06-21 16:31 评论0 收藏0
业务安全通用解决方案——WAF数据风控

摘要：然而业务安全场景，识别用户身份评估用户信誉是业务风控的重要依据。数据风控服务的价值回归到文章开始的问题，业务安全防控如何成为业务促进者，数据风控服务能否达成这个目标答案是肯定的。你们安全不要阻碍业务发展、这个安全策略降低用户体验，影响转化率——这是甲方企业安全部门经常听到合作团队抱怨。但安全从业者加入公司的初衷绝对不是阻碍业务发展，那么安全解决方案能否成为业务促进者，而非业务阻碍者呢...

caige 2019-06-21 16:29 评论0 收藏0
听说支付宝有一个“疯起来连自己都打”的项目

摘要：支付宝疯起来连自己都打的项目就是红蓝军技术攻防演练，他们不仅每周进行全栈级别的演练，每年还会举行规模极大的期中考试和期末考试。在支付宝，蓝军从属于蚂蚁金服技术风险部，而红军则包括及各业务部门的技术团队。摘要：红军 VS 蓝军，谁是更强者？小蚂蚁说：自古红蓝出CP，在蚂蚁金服就有这样两支相爱相杀的队伍——红军和蓝军。蓝军是进攻方，主要职责是挖掘系统的弱点并发起真实的攻击，俗称...

trigkit4 2019-06-21 16:50 评论0 收藏0