登录
汇金资损防控体系建设及实践 | 得物技术
一、为什么要做资损防控
随着互联网电商平台竞争的加剧，各平台的业务复杂度不断提升，线上环境的稳定性面临更大挑战。在汇金领域，由于其高资金属性，除了确保链路可用性达到99%以上，防止资损亦成为关键保障事项。得物汇金业务涉及复杂的资金流和大额资金敞口，因此实施资损防控尤为重要。
-
防资损、资金安全
-
保障企业财务健康：
资损防控措施能有效识别和应对风险，保护企业现金流和资产，维护股东投资收益。
-
降低风险敞口：
面对市场波动和欺诈等风险，实施资损防控能显著减少对企业财务的负面影响。
-
增强抵御危机能力：
在经济不确定或突发事件（如市场崩溃、疫情等）发生时，稳健的防控措施帮助企业保持资金流动性和安全性。
-
防客诉
-
提升客户信任：
资损防控有助于提高服务质量和客户满意度，降低资金管理不当造成的风险，从而增强客户信任。
减少客户投诉：
不当的资金管理可能引发服务延误和错误收费，良好的防控措施可避免这些问题，确保客户顺畅的服务体验。
维护品牌声誉：
客户投诉频繁会影响品牌形象，实施有效的资损防控可保持良好的客户关系，并促进长期发展。
经过不断的演进与发展，我们已经沉淀出一套汇金资损防控体系的方法论，并在实践中取得了一定成效。因此，我们希望通过知识梳理与分享，鼓励大家共同交流学习，持续推进资损防控的提升与优化。
二、如何做资损防控
整体方案：
开展思路：
根据平台特性，涉及到交易和资金流，就会考虑到是否会发生资损，那么如何避免产生资损，总结出一套适合业务特点的方法便成为资损防控的关键。汇金平台和业界内的其他平台采用的资损防控方法论基本一致，但是不同的每个阶段所覆盖的产出的内容不一样。
从项目全生命周期来看，已发布时间和出现问题时间为时间点，发布时间前的阶段为事前阶段，出现问题的时间点为事中阶段，出现问题后应急响应为事后阶段。
-
事前
-
阶段：项目发布前的时间段，在这段时间内会经历需求评审、研发设计评审、测试用例评审、稳定性项目评审，我们要从4个关键事项对焦如何从需求、代码、线上核对/监控等发现手段上做到防资损、及时发现资损问题。
-
关注的内容：需求层面，挖掘是否直接涉及资金流，或间接涉及资金流，如果涉及资金流，了解资金如何进行流转，进而挖掘到资金流涉及的上下游。技术设计或编码层面，实现资金计算的逻辑、计算公式，明确上下游之间的资金交互元素、金额/币种/单位，持久化资金数据，异常监控报警逻辑，业务单据幂等逻辑，资金平衡校验等。测试层面，从正常流程和异常流程验证代码实现逻辑是否符合预期，如资金计算、金额大小、方向、币种、单位，上下游传递，数据存储等，基于验收通过后的逻辑编写自动化，自动化要核对金额的正确性，用编写自动化目的是为了沉淀资金场景的测试手段，为后续迭代改造的保证质量及提高效率。
-
事中
-
阶段：生产环境出现问题的阶段，对于不同的问题发现有不同要求，重资损链路要做到1分钟发现，即系统出现问题后1分钟发现，系统有告警。从系统告警后5分钟内介入做出响应，即5分钟内有人看到告警并进行跟进。所以重资损链路的问题要做到1-5。非资损链路可做到D+1发现，D+1介入和修复即可，相比资损链路而言，发现能力没有太强要求。如果没有问题的发现能力，最终可能会导致资损的慢性流血发生。不论线下环境如何测试，都很难保障测试环境100%覆盖，所以线上问题的主动发现能力尤为重要。
-
关注的内容：系统出现问题后，是否有实时或者非实时的告警能力。对于告警内容，要根据业务优先级及系统实现，编写实时/非实时核对脚本。如果业务复杂性高，可以编写抽检脚本，就是系统实现的重算逻辑，从旁路发现问题。那么如何验证脚本有效性，发现问题是否进行报警，就要进行攻防演练。通过演练，可以检查是否具备问题的能力，以及开发的响应能力，如果不达标，要进行改进和优化直到达标。
-
事后
-
阶段：发现问题后的止血阶段。一般分为两方面：当前问题的扼制，不再新增问题；存量问题的解决。止血应急能力要有相应的预案或者建立新的应急能力。如果止血比较快，能降低问题的影响，如果止血比较慢，可能会扩大问题的影响，提高问题的严重等级。
-
关注的内容：对于资损问题要做到10分钟的止血，从发现问题到消除增量问题产生，要在10分钟内解决。对于存量问题的解决，可根据业务特性，在相应时效内修复即可。在修复前可以通过挂公告的方法，暂时消除或者降低问题事态的影响。对于比较核心或者比较固定的问题，可以形成执行预案，当发现问题后，可及时执行预案进行问题止血。对于比较复杂的业务，要根据不同的问题及时进行编码修复问题。不管是进行代码或者编写预案代码，如果涉及代码修复，开发测试均要参与保证代码的正确性。如果只是一个角色进行修复，可能会因为预案问题导致的二次事故发生。
三、资损防控产出阶段
对于项目实施阶段，当承接新功能、新建系统或者分析存量系统时，如何判定是否要做资损防控，可以从两个角度出发分析：信息流或者资金流。资金流和信息流之间是相互依赖的。当业务需求中涉及资金流时，系统要实现业务需求，那么系统之间就要设计信息如何流转最终完成资金流转。当系统中存在资金字段的信息流时，可最终推导出直接或者间接的资金流。资金流通过信息流实现资金流转，信息流是资金流转的载体。所以当信息流中存储或者涉及资金交互，资金传递时，就要做资损防控，分析资损场景及如何编写资损脚本。
对于项目发布后阶段，当项目前期如果没有做资损防控，那么也可以从线上稳定性来看是否要做资损防控。一般可以从线上故障、线上工单等结果分析需要做的资损场景有哪些。从线上问题来看可以比较直观的看到缺少哪些防控手段并做针对性的补充，这样能起到立竿见影的效果。这种是从问题点切入的方法进行分析跟进，但比较好的做法是从面上进行分析，集合需求、问题全面分析，从多个点同时作为抓手判定资损防控的必要。
以上两个方法，均在汇金域进行了实践，在项目发布前和发布后都会进行资损防控补充。
四、如何挖掘及度量资损防控规则
当要实施资损防控时，如何挖掘实施资损规则变得尤为重要。当规则挖掘的不对或者偏少，不利于及时发现问题。当规则过多时，对规则的投入成本会变高，规则保鲜会成为挑战，最终也会影响到发现问题的及时性。
那么如何比较全面的挖掘资损规则呢？目前汇金域从三方面切入，分析资损规则并推进资损防控覆盖的成熟度度量。我们从这3方面进行资损规则分析并编写规则脚本，完成资损布防。
- 资损字段覆盖度量
- 业务指标覆盖度量
- 跨域资金安全覆盖度量
资损字段覆盖【字段】
当系统链路涉及的数据库有资损字段时，在Dcheck平台上做资损字段标记，资损字段标记资损，非资损字段标记非资损。从字段上挖掘到要有资损规则覆盖。当在Dcheck上编写完对应规则后，要进行字段和规则的绑定，维护字段和规则之间的关联关系，这样也可以在报表上看出来资损字段是否有对应的线上布防能力。
字段层面覆盖是比较简单可以做到的资损规则分析，常见的资损字段如金额、币种、单位、汇率、计算公式、数量、日期、状态等。如果链路中涉及这些字段，都可以进行对应的规则实施和布防。一般此类字段覆盖的规则可以通过实时核对实现，这种正确性时效要求比较高，如果存储不正确也比较容易发现问题。资损字段覆盖是比较入门并快速上手的手段，但不能作为发现全部资损问题的手段之一。除此之外，还需要通过其他方式挖掘规则。比如字段内容正确，但是其他指标异动方面较大有影响，这种从字段覆盖层面无法发现问题。
业务指标/场景覆盖【业务】
不同的业务域关注的指标不一样，但可以通过观测这些指标可以发现潜在的问题，进而避免可能产出的投诉或者扩大影响。常见的业务指标比如：时效性巡检、成功率异动巡检、失败率异动巡检、中间态异动巡检或者其他指标异常巡检。通过对这些指标的监控覆盖，可以补全数据正确但系统有问题的发现手段。一般业务指标类的覆盖时效性不高，非实时核对方式实现，可能是D+h或者离线D+1方式实现。
上下游资金安全覆盖【跨域】
资损字段或者业务指标覆盖，更多的是聚焦在内部的稳定性上面，对于和外部间资金覆盖较少。当然资损字段可能也会涉及到外部之间的核对，但上下游之间的资金安全覆盖会涉及更多，可能是直接的上下游资金覆盖，或者全链路上的非直接上下游的资金场景覆盖。常见场景如：下单支付场景，订单域的支付金额和支付域的金额、状态一致性check，各种费用项的一致性校验；采购结算付款链路，付款场景下的金额要和采购结算单据的金额币种保持一致等。通过在发生资金流转的时间，做上下游资金安全check，能和业务侧的金额做校验，进而保证流转的资金安全。
业务域度量探索实践效果
- 建立核对场景分层覆盖策略，围绕字段/业务/跨域开展。
- 探索定义各层级的度量方法，并在各子域实践落地，经过与对应功能开发owner对焦，确定了度量方式的有效性。
- 示例如下：子域2025Q1落地结果，核对覆盖率100%（平台配置采用率100%，共120+个业务场景，60+个跨域场景覆盖率100%；资损字段30+个，核对覆盖率100%）。
五、如何选择资损实现方式
得物实现资损防控的平台为Dcheck平台，作为实现线上核对的平台，支持资损场景核对或者非资损场景核对，从时效性上实现了实时核对或者定时巡检，也支持配置变更的核对。数据源上支持监听生产环境数据库的binlog消息，连接离线数仓、连接业务库。支持语言上可以用Groovy语言编写核对脚本，离线数仓或者通用SQL编写SQL脚本进行核对。同时支持对编写的脚本进行演练，检查脚本有效性。当发生报警后设置通知群@到具体人进行日清处理。业务域可以根据业务特性灵活选择不同的实现方式满足业务目标。平台本身支持的能力比较多样化，灵活性也比较强，支持各种变更的核对。
-
实时核对原理
通过实时监听binlog消息/自定义消息/实时数仓消息，触发规则核对。监听binlog和自定义消息的脚本要用Groovy实现，监听实时数仓消息要用SQL实现，Groovy实现的规则会涉及到接口间调用，会出现超时发布导致调用不同的情况，稳定性有一定影响。用SQL实现相比起来更灵活更稳定。监听实时数仓的前提是数据源要接入实时模版平台。
-
定时巡检原理
定时巡检是通过配置定时任务触发核对，核对脚本可以通过离线SQL或者Groovy脚本实现，Groovy脚本可以连接业务数据库，比实时核对有小时级别或者天级别的延迟。离线SQL的延迟就是D+1。对于时效性不高的规则场景可以使用此种方式。
- 核对方案选型
六、如何做资损防控运营
迭代需求运营
-
汇金独立项目&迭代资损布防：日常迭代或者项目如果涉及到资损防控，有一套运营流程机制保证资损场景的分析及布防。
-
当需求涉及到资损时，会对需求进行打标标记。
-
在测试用例评审时，编写资损场景及组织开发评审，保证场景有效性。
-
目前按照RDC“资”需求打标--->测试用例打标资损用例--->Dcheck规则实现--->用例平台绑定Dcheck规则运营流程推进。
-
在测试前置阶段完成资损用例分析，高优资损场景在预发、生产流量发布前完成资损布防，低优场景在放量一周内完成规则实现，分析到的核对场景布防率100%。
-
在生产环境有流量前实现资损规则并进行演练，推进上线状态。当线上数据触发报警时，有值班人员跟进日清，如果发现bug，会在系统上标记bug并进行bug修复。整体流程也会不断进行复盘和review，提升资损防控的投入和产出价值。
-
-
研发测试分工：目前迭代或独立项目通过Dcheck方式实现的资损场景主要是测试负责推进，一般在项目开展时或项目灰度前推进完成。涉及的资损场景，测试会邀请开发进行评审。对账平台实现的离线核对场景及实现主要是开发负责，一般偏于迭代测试周或者后续迭代进行开发实施，测试参与度低。
-
关于Dcheck规则报警，测试报警后会做初步排查，然后确定不是脚本问题后@对应的开发介入处理，开发负责协助进行问题分析，如果是代码bug或者数据问题，开发进行紧急或者排期修复。
-
测试过程中，如发现资损风险，不适合Dcheck手段布防，开发添加监控。
-
-
资金SOP验收执行：
背景：汇金属于强资金业务线，涉及的资金敞口大，资金流错综复杂，其资金安全对稳定至关重要。为规范资金需求类的产品研发流程，避免低级流程问题导致的资金安全问题，需规范各职责角色和产出，确保需求流转过程中的高效协作和最终交付质量。
验收方案：整体流程如下：
如何做资损规则保鲜
-
保鲜策略：
目前通过提出保险管理策略，平台实现后，让用户发现规则的有效性和质量，及时发现僵尸规则，做到规则保险。
保鲜策略如下：
- 一段时间内核对失败占比，时间支持选择；
- 核对无执行记录；
- 状态为下线规则；
- 无演练记录或者演练失败的规则。
-
保鲜运营：
保鲜功能Q4上线后，汇金域内完成存量僵尸规则治理。且随着资损防控成熟度建设，场景规则有效性已作为成熟度指标之一，保鲜治理已随迭代常态化运营。
-
子域1：下线24个规则，剩余规则全部有效
-
子域2：下线12个规则，剩余规则全部有效
-
子域3：下线8个规则，剩余规则全部有效
-
子域4：下线6个规则，剩余规则全部有效
-
子域5：下线6个规则，剩余规则全部有效
-
如何做资损规则日清SOP
明确目标及范围：针对业务巡检、实时核对报警，梳理告警跟进SOP，形成闭环处理问题流程，确保资损防控处理的高效性和处理一致性，提升日清率，降低误报，提升有效问题发现。针对资损问题进行日清，同时也是资损成熟度的指标，随迭代运营开展。非资损问题发生报警同时也会进行日清处理。
具体的操作步骤：说明资损防控告警运营的具体步骤，见下图，需要清晰易懂，确保操作性强。
责任人：说明具体步骤对应的责任人，以及不同步骤需要知会的人，确保问题有效推进解决。
监督措施：定期评估SOP的实施效果，并进行必要的改进。监督机制的设计应该确保SOP的执行情况得到有效监督和管理，保障SOP的实施效果。
各步骤定义说明：
资损发现问题复盘模版：
示例：
七、资损防控实践及收益
汇金域通过资损防控专项的实践，不断总结沉淀出一套体系化的方法：需求识别资损规则-->如何分析资损规则-->如何选择实现技术。此方法可以降低人员对资损防控专项的学习门槛，提升学习效率。通过挖掘资损规则的方式，可以较快分析产出资损规则。通过学习实现方式，能较快的选取合适的实现方式，减少试错成本。
自2024年全年至2025年5月共完成了520+个规则，发现了160+个问题。其中5+个问题为资损问题，155+个非资损问题。有效遏制了线上的资损发生和有效保障了线上稳定性。
利用Dcheck手段，降低客诉明显。
- 核算&发票巡检及发票接入配置化项目：通过不断通过完善发票平台线上巡检，制定各类配置问题跟进的SOP，共产出8类配置巡检规则，成功将配置等工单问题从15降到0且持续保持平稳。配置类问题线上问题主动发现率100%。
- 来自TS反馈：
- 子域有明显下降趋势，整体降低41%(业务咨询减少&配置类治理有显著效果)。
八、总结及规划
经过汇金在资损防控专项的体系化建设及实践，取得了显著进展。从事前挖掘资损规则、代码预防性建设，事中及时布防资损规则、巡检规则、开发添加监控，事后及时执行预案以及补充未布防场景规则，以及经过各种挖掘资损方法的探索及分享，大部分员工具备资损防控意识和资损规则挖掘、布防、日清保鲜的能力。并且在整个推荐过程中，研发测试协同分工，共同保障及推进线上稳定性稳步提升。目前体系化流程已初见成效，后续除常态化运营继续开展外，让全员具备资损防控意识，同时也会重点治理以下环节中的痛点问题，不断提升专项的ROI。
-
资损分析：AI资损场景分析
目前资损分析从三层架构出发，沉淀了一定的规则规律逻辑，后面尝试AI推荐资损场景分析，减少人工输出成本。
-
脚本实现：通用SQL降噪
目前通用SQL实现的脚本规则噪音比较大，因为Flink平台底层数据存储在Redis，当多表比对的时候，会出现单表查询Redis超时，对比不一致的情况。后续尝试支持重试或者其他方案降噪解决问题，减少噪音干扰和降低人工成本。
-
降噪归因：报警自动归因日清
随着业务复杂升级，资损规则不断增多，脚本失败报警日清处理成本会越来越高，同时随着AI应用普及，尝试通过AI自动归因日清，进一步降低人工投入成本。
往期回顾
2. Cursor Rules优化实战：构建高效稳定的AI代码生成规范体系｜得物技术
文 / 文姬
关注得物技术，每周更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～
未经得物技术许可严禁转载，否则依法追究法律责任。
