浅谈交易域的资损防控
一、概述
我司作为电商公司，稳定性，安全，资损防控是我们业务和系统的底限。因此资损防控建设是交易平台的重点一环，我将所有可能的资损场景梳理出来，然后通过技术优化、数据比对等方式尽可能规避问题发生。最后通过实时监控，业务预警等方式及时发现、止损，减少业务的资损。
二、资损定义
资损定义：任何由于产品设计缺陷、服务故障、中间件故障、员工操作错误等导致公司或客户蒙受直接或间接的资金损失。
关键点：
资损产生的原因：产品设计缺陷、服务故障、员工操作错误等。
资损产生的后果：给公司或客户造成直接或者间接的资金损失。
广义上，只要是系统运行后的资金和业务预期的资金不一致，都算资损事件。在资损故障处理过程中，如果资金还在公司体系内，比较容易处理，最终不会造成实际资损。但是资金一旦出了公司体系内，到了用户手中，造成用户损失的，公司必须赔付，如果是用户获利的，公司比较难追回。因此对于涉及用户的资金流出，是资损防控的重点。
三、整体方案
大部分资损是由应用服务和数据不一致导致的，因此资损防控建设需要围绕应用服务和数据来重点把控。
不论是系统故障、中间件故障还是代码bug导致的资损问题是不能完全消灭的，但是我们还是可以通过一些方法和手段，尽量在产品上线之前规避掉资损问题（规避能力），如果产品上线之后发生也要能够及时发现（发现能力），发现之后能够及时应急处理（应急能力），降低资损事件造成的损失和影响。
基于上面的结论，资损防控的整理方案包括三个部分：事前规避，事中发现和应急措施。下面是整个资损防控建设图。
3.1 事前规避
3.1.1 资损场景梳理
梳理出业务域所有可能产生资损点的场景，可以参考领域建模的事件风暴，相关同学通过高互动的方式，快速梳理出所有的资损点的，避免有遗漏。然后按照资损点涉及的相关业务域进行分类。
具体针对资损场景建设时，可以按照理论资损值确定所有场景的重要紧急性。
补充说明：资损防控建设不是一个一蹴而就的事情。随着业务发展，会有新的资损点产生，需要在业务发展过程中，持续分析与建设。可以将这块工作放到技术方案设计和评审环节进行不断完善。
3.1.2 技术方案设计 - 包含资损防控模块
技术方案设计有时比编码更重要，因为技术方案是从全局考量，避免落入代码实现的细节。技术方案不仅可以保障领域服务的持续、稳定演进。同时还需要考虑容错方案、针对性的梳理出资损和故障点，并建设相应的监控、降级策略、止损方案等。
在技术方案设计时，针对资损防控需要重点考虑下规则配置变更、数据不一致、越权访问、服务和中间件故障等影响，一个大的业务功能，需要在方案设计时考虑功能上线时可监控、可灰度、可降级。
3.1.3 研发规范
对于后端开发，主要的研发规范包含如下：
编码规范 + CodeView规范 对于编码规范推荐大家接入Sonar，方便进行代码质量管理。 日志规范 + 告警规范
SQL规范 + 数仓规范
代码分支 + 合并规范 服务发布规范
研发规范包含的内容很多、各组可以业务+研发情况展开讨论，确定之后团队严格执行。
3.1.4 自动化测试回归+故障演练
自动化测试是一个低投入高产出的工作，通过自动化测试用例覆盖所有的资损点，可以在自测、提测环节就发现本期功能迭代中是否有代码被误改，配置变更错误等。通过跟进排查具体原因，可以提前规避掉很多风险。
故障演练是为了检验系统质量，团队对线上问题的快速响应与应急止损能力。通过故障演练+复盘机制，发现目前系统存在的问题点（包括资损点），通过技改进行优化，同时建立对应的降级止损预案。方便在线上真实发生问题时的应急处理。
3.2 事中发现
事中发现的建设主要包含如下两点：
数据核对的建设-发现业务信息，如库存、金额不一致的情况；
监控告警 – 发现服务异常、中间件异常、OS异常等。
对于发现能力 - 是否做好的关键的指标是覆盖率和时效。只有将所有问题点都覆盖到，同时尽快告警出来，才能将问题风险降到最低。这里重点介绍下数据核对的建设。
3.2.1 数据核对
为什么需要数据核对，主要有以下几点原因：
保障系统稳定性
减小内部和外部数据不一致的风险
避免人为操作的失误
3.2.2 数据核对的原理
数据核对主要分为离线对账和实时对账两种，对于资损防控场景需要较高的实时性，尽快发现及时止损。我们实现的数据核对功能主要包括数据触发、事件构造、获取规则、规则执行、结果储存和对异常数据的告警。
数据触发：对于源数据，业界一般通过两种方式，一种是业务处理成功之后发一个MQ，然后关联的消费者收到消息进行数据核对，第二种是模拟MySQL主从复制的交互协议，伪装成一个MySQL的从节点，监听MySQL的binlog日志，然后转换为便于读取的结构化数据。个人推荐使用第二种，实现了服务之间的解耦，减少了系统的负载。我司也是采用的第二种方案。
事件构造：读取到结构化数据后，剔除部分无效数据，然后封装自己关心的核心比对数据，作为规则执行的入参。
规则获取：根据资损业务场景区分大类，拆分不同的规则。然后具体某个资损场景里面，根据数据状态区分小类。然后利用规则工厂，统一管理生命周期。
规则执行：可以参考规则引擎，即实现规则的高效管理、复用，还实现相应的规则决策计算， 同时针对某一维度的聚合（如对同一用户的多条请求进行累计）确认是否命中规则。
补充说明：得物的规则执行，可以自定义延迟执行时间和采样率。
结果存储：对于规则执行流程和结果，需要进行相应的记录。
告警：对核对不通过的，异常的数据的数据，需要进行告警，帮助业务人员快速发现资损。
下面就重点说下得物基于Dcheck的发现机制。
3.2.3 基于实时对账的发现机制
不同资损场景在执行完不同核对规则之后，对于核对不通过、异常的数据。Dcehck会按照业务配置的间隔时间，定期统计某个时间窗口内的失败数，然后通过不同的通知方式（业务可以根据重要性，采用不同的告警组合）告诉到业务和开发人员，然后执行相应的应急措施。
3.3 应急措施
线上发生资损情况，大多都是因为逻辑缺陷和代码bug，这个时候通过排查详细原因、hotfix、代码回滚等操作都会加大资损量，同时有一定的业务风险。因此应急止损能力的建设，主要围绕快速完成服务降级来建设，关键包括服务降级、止损预案和SOP。对于线上发生的资损，有一套相应的止损操作，能通过业务降级、止损预案等配置变更完成第一时间的止损。
3.3.1 服务降级
根据服务的强弱依赖和接口耗时两个维度进行梳理，拆分出不同的模块组件，每个模块再确定相应的降级策略（业务降级策略需要跟业务和产品确认后再进行开发）然后通过模块化的方式实现代码功能的复用。
3.3.2 止损预案和SOP
通过对资损场景的分析确定对应的止损措施，提前建立相应的止损预案和SOP文档，这样团队在出现问题时可以简单、快捷的完成应急止损。
对于建立的止损预案和SOP，可以通过故障演练的方式去检验其功能完备性和处理时效性。
补充说明：对涉及到资损防控的预案需要设置为手动开启，不要系统自动触发。预案开启前需要尽快告知到业务和产品，等业务和产品进行确认后在手动触发。
四、出价&库存资损防控建设
出价&库存团队的建设目标“1-5-60”，即1分钟发现，5分钟止损恢复，60分钟解决问题。整个团队梳理了目前存在的资损场景，然后针对每个场景，根据事前规避、事中发现、应急措施三个维度进行详细梳理，然后按照理论资损确认建设的重要紧急性，进而确认所有资损场景建设的先后顺序。下面重点介绍下资损场景-超低价防控。
五、资损场景-超低价防控建设
5.1 背景介绍
资损场景-超低价是指得物平台卖家以低于该商品目前最低价、历史成交价很多的价格出价，被买家成功购买后导致卖家的资金损失。
由于得物平台不限制商家出价的，对卖家不小心出超低价是不能强制干预的，只能通过一个预警功能进行实时监控，类似规则引擎的离线模式。
关于资损场景-超低价防控建设，主要包括事前规避、事中发现、事后应急措施等。
事前规避
业务优化：包括优化超低价弹窗文案-资损金额展示、扩大出价规则的校验场景等
技术优化：出价规则缓存一致性治理
建立自动化测试用例
2. 事中发现
建立超低价预警功能
超低价实时监控大盘
风控监控大盘
3. 应急措施
a. 预案：防超低价-在售库存临时下架
其中需要重点建设的是：超低价预警功能。
5.2 超低价预警功能-技术实现
对超低价的实时发现，需要监听出价服务新增/修改出价事件的binlog，这里采用公司的实时对账工具-Dcheck，完成数据触发和事件构造。
目前Dcheck的执行流程，主要是通过binglog数据源触发，然后通过http或rpc接口获取对应的比较数据。在Dcheck里面进行规则的匹配和处理，对于异常数据触发告警。但是对于超低价场景而言，由于以下三个原因：
需要比较的数据源较多（包括最低价、出价金额上下限、修改出价操作的前一次出价等）；
每个策略规则也比较复杂，需要考虑百分位差和绝对值位差等，不方便放在dcheck脚本中进行维护；
后期的止损功能建设。
于是采用了如下交互方式：
即通过Dcehck将新增/修改出价数据传入预警接口，然后再该功能中利用规则工厂完成所有的校验逻辑，最后将触发超低价的数据传回Dcehck，复用Dcheck的告警机制和数据大盘，完成相应的预警功能。
5.3 规则工厂
由于超低价发生在出价域各个场景中，比如新增出价和修改出价，活动出价和非活动出价的规则也不同。需要比对的数据源多，不同数据需要执行的规则策略也有差异，因此在技术方案设计时借鉴规则引擎的思路，根据不同的出价特征，确定不同的规则策略，不同出价场景执行不同的规则策略。
为了满足预警功能的持续演进：
建立规则工厂完成对不同规则策略的管理。
采用策略模式和模板方法模式（见下面UML图），将相同功能进行抽象复用，也方便今后添加新的策略规则。
在接口里面定义面向超低价预警功能的规范，在抽象类里面实现一些基础功能和可复用的模块（方便后期模块化建设），然后各个实现类里面实现各自的规则比对逻辑。
今后如果有新的规则策略（如利用数仓回流，获取最近已成交的均价作为比对数据）可以直接继承抽象类，复用其已实现的功能模块，再实现自定义的规则逻辑即可，方便预警功能的持续演进。
5.4 UML图
对于超低价的资损防控建设，根据业务特性和数据状态分为4个规则类。然后通过策略模式和模板方法模式将4个规则类的相同功能（如百分比校验、位差校验等）进行抽象，在具体策略类根据不同类型进行具体规则逻辑的实现。
5.6 重要提醒
主要有两点重要提醒，一是基于Dcheck的实时比对方案对线上服务有代码侵入，需要考虑Dcheck请求流量对系统负载的影响，制定相应的灰度策略和限流方案；二是在上线前需要对接口进行压测，了解对应的接口性能确定限流阈值。
六、总结
文本主要介绍了交易域的资损防控能力建设，整体方案包括三个部分：事前规避，事中发现和应急措施。然后针对各部分进行拆解，细分到可以执行的任务。在这个过程中，需要注意：
针对不同的资损场景，需要根据业务特性抽象问题，制定完整的发现机制和对应的止损预案；
尽量复用公司现有的平台能力，这样即可以把精力聚焦在解决核心问题上，同时也可以和平台一起进行迭代升级；
数据核对功能，尽量和应用服务进行解耦，避免数据核对功能对线上业务的影响；
具体到规则执行，可以使用策略模式和模板方法模式，将相同的功能进行抽象封装，然后对不同的对账规则进行相应的策略实现。
发现资损告警，然后第一时间执行对应的应急措施，将客户和平台的资损风险降到最低是资损防控建设的核心目标，也是检验成果的最要指标，保障交易业务更加安全、稳定的运行。
*文/Monin