前言
近两年随着交易系统承载的订单量从开始的万单/日快速膨胀到百万单/日，交易GMV也快速膨胀到千万级，系统一旦发生故障，每分钟的峰值资损将达到几十万，这是一个完全无法承受的损失。
在此背景下，博主最近两年也一直致力提升交易系统稳定性的水位线，借此机会在这里和广大朋友一起探讨，有好的想法欢迎文末留言一起交流共同进步。
建设思路
业界参考
从参与建设交易系统1.0版本迭代到3.0的过程中，中间做过一些局部稳定性架构升级（比如存储架构升级），类似于哪里着火就去哪里救火，不断的对系统进行缝缝补补，但没有通盘做过稳定架构升级治理，更没有做过交易类系统的稳定性架构升级。
在这样一个背景下，只能从公司内&外部头部厂商进行调研，这里主要参考了公司内部交易团队以及美团、蚂蚁金服等外部团队的宝贵经验，得出一个通用的治理思路。
图片
按照事前、事中&事后三阶段的思路，梳理总结各阶段重点事项和具体执行方案，梳理如下图所示：
图片
通过大图得出明确的治理目标，通过治理使得系统能够做到不重（不会重复计算）、不漏（不丢单）、不错（资金不算错）。
其次根据业界资金治理思路，资金安全保障治理重心围绕主动防御手段、快速发现能力、快速止损能力的优先级依次展开对应的风险治理项，这其中尤其会将绝大部分精力致力于在事前阶段通过各种主动防御手段将问题扼杀在摇篮里。
明确了针对资金类系统的治理目标，接下来需要确定具体执行路径：
图片
“面”、“线”、”点“链路梳理
链路梳理思路围绕“面”、“线”、“点”依次展开，
i). 以资金流向图为“面”作为切入点，看清楚交易系统整体运转情况，
ii). 然后基于资金流向图，深入到每一条资金流向链路，梳理出这条链路的业务流程图，以业务流程图作为“线”，分析出业务流程中的上下游，以及业务自身的流程；
iii). 明确“线”之后，进一步深入到每个关节环节“点”上，以“漏”、“重”、“错”三个维度去分析可能产生的资损情况，然后针对性的进行对应的资金安全加固。
一个简化版的梳理和治理case
- 梳理资金流向图
图片
- 梳理业务流程&治理&验证
图片
i). 基于第一步梳理的资金流向图，按照业务重要程度的优先级，深入到代码实现层面，绘制出整条业务线的实现业务流程图;
ii). 分析业务流程图中各环节可能出现的问题；
iii). 针对问题制定相应的治理手段，明确后续落实的责任人&加固节奏；
iv). 对于各项风险项完成治理后，接着开始进行有效性验证，有效性具体验证手段一般有系统故障演练和业务故障演练（比如手动注入各种异常来模拟真实情况的发生、配置扰乱等手段），观察系统的真实表现是否符合预期；
v). 对于演练发现的非预期表现，进行二次加固后再次验证；
vi). 对于有效性加固后可能产生的一些“噪音”（比如监控报警、对账异常等）进行降噪处理;
各阶段具体治理手段
- 事前阶段
资金代码安全扫描，在开发阶段，每次提交代码后，在ci/cd流水线上，基于通用的扫描规则，指定针对交易系统特有的规则，比如命中特定关键字“yuan”、“cny”、“account”、“money”，则在代码提交测试前直接阻断，需要有研发RD针对性检查业务逻辑是否符合预期，同时测试同学也需要针对性的设计响应的case，保证测试一定能够覆盖到。当以上工作完成后，由研发手动确认后，才会正式流转到测试阶段。
- 事中阶段
对账能力，对账分为系统间对账和系统内对账，对于上下游系统之间进行数据一致性对账，通过上下游两方或者多方的DB数据，设计响应的对账规则，然后通过对账平台的近实时对账能力，对线上数据实时进行监控，遇到数据不一致时，通过告警人工及时介入排查和对数据一致性进行补偿处理。
- 事后阶段
SOP最佳指导，对于系统比如支付环节，发现商家存在违规刷单、异常交易等行为时，通过提前梳理好的SOP手册，对其进行支付、结算、提现能力的快速封禁，防止资损情况的进一步放大。
以上对各个环节进行了一些具体实施手段的展示，在整个治理过程中，我们还做了大量的其他工作，比如系统内的对账能力建设、配置扰乱、红蓝对抗等等，如果有想了解的朋友，我们专门在出几篇文章来展开聊聊。
总结
本文介绍了资金系统如何进行加固升级的一个整体实施思路，另外整个核心治理思路可以迁移到任何系统的稳定性治理，在生产环境真正落地的时候需要根据自身业务场景进行适当调整即可；同时在具体落地的时候，需要对各个环节进行方案充分设计和讨论，以防在稳定性治理过程中产生的系统故障。
