Tech
导读

面对复杂的系统问题，通常倾向于采用简单的方法来解决。本文介绍了一种有效提升基金交易系统稳定性的预警监控方案。文章的重点不在于实现方案，而是一种思维方式。例如，如何寻找关键点进行分析，以及如何确定问题点进行决策。希望本文能够给大家带来一些启发。

前言

在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！

简介

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

买基金，来京东

基金交易系统是用户使用京东金融APP进行基金交易的核心支撑系统，每天有数十亿元的交易额。

在大额的交易面前，系统的稳定性尤其重要，同时基金业务比较复杂，为保障每个地方的稳定，告警埋点很多，加上各种日终检查，看似很完美，实际却有了新的问题，因告警太多，日检滞后，而无法快速处理有效异常，导致对账延迟和引发客诉。

结合日常处理经验，重新思考是否有好的方式，提前发现异常，改善此事，于是在基金交易系统中做了一件事情，有效的提高了系统的稳定性，以下为此事的主要效果。

工单数量：相对2022年1-6月的客诉总数(334)减少127个；对账时间：稳定在16点半前完成；异常订单：从每天几个变成偶发出现，；后续流程：比以往有了较强的稳定性，同时也间接的释放了，因客诉异常引起的资源消耗（客服，产品，研发，工程师），提高了用户一定体验和满意度。

什么事项

为基金交易系统增加了新型的异常预警，能更加有效的提前发现系统异常，快速解决。

为什么做这个事情

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目

在基金交易中，每天有几十万的订单，交易额有数十亿，基金业务场景不仅又多、又复杂，而且链路也比较长，盘后的数据检查经常由于各种原因出现异常订单（运营配置错误，基金公司下发文件异常，系统bug等），而无法顺利对账，影响后续流程。排查定位和修复问题，需在2小时内完成，如果超过时长会对后续流程造成严重的影响，所以有效异常的提前发现和预警就非常重要。

基金交易系统异常告警无法满足吗？

交易系统中现有2种告警，一种是即时告警，一个日终报警。

即时告警，由于老项目时间久，存在历史原因，每天会收到数千封即时告警邮件，想筛选出真正的有效异常,变得非常困难，还有一定的时效性。

日终报警，是在每日交易结束后，系统会自动进行日终检查，如果发现异常，需在2小时内解决，而且只能对已发生的结果进行修正，个别异常还好，如果出现批量异常，那么2小时就非常宝贵。短时间内的修复，不仅存在高压出错的风险，还可能因此对后续流程产生隐患，甚至对用户造成影响，引发客诉工单。异常工单的处理，是对客服、产品和工程师一种消耗，而且在微服务架构中排查和解决更加复杂耗时。总之每次对账出现异常，总是非常紧张。

你做的预警有什么特点

1、是即时告警和日终报警的补充

2、可通过手机一个界面随时观察异常变化

3、15分钟内即可发现疑异常订单

4、可快速定位，精确到重要场景

预警具体怎么做到的呢？

首先对账能否顺利，取决异常情况，而异常又无法彻底避免，提前发现与控制就非常重要。

图2.

7.1 制定异常发现和处理策略

面对告警过滤困难，日终滞后，结合历史处理经验，对系统进行再次思考，是否有更简单的方式，能有效的对异常进行实时发现预警？

通过探讨，总结了一个简单的规律：

如果关键点没按照指定时间内变更，即可定义为可疑异常，其严重级别可以通过汇总数量进行表示。

于是制定了如下策略：

图3.

7.2 指定监控预警技术方案

1：首先要基于本身的业务进行识别，基金交易对账是对订单的最终标记状态校验，我们假设一个支付的订单，如果在15分钟内，订单的状态没有发生变化，是否设定为可疑异常？其原因可能很多，如网络问题、MQ消息延迟、代码BUG等等，总之是有问题，那么这样的订单数量越大，就代表其影响的订单就越多，对账的风险就越高。

2：关键点的异常识别，可以采用同样的逻辑，如果在指定的时间内，关键点的状态没有发生变化，即可设定为可疑对象，比如基金交易的重要场景：申购，赎回，支付，非交易过户，退款等场景，都可以基于场景数据的状态变化或者MQ的积压情况进行识别，举个申购的例子：用户申购完成后，后续的流程是采用MQ和任务的方式执行，每个任务都有初始和完成状态，如果这个申购任务在15分钟内，没有标记为完成，即可定义为可疑异常，此类的状态的任务越多，影响对账的风险就越高。

图4.

落实技术方案

图5.

实践中验证效果

效果：刚上线只对总订单和2个场景加了预警，慢慢增加到11个场景，效果也很明显，异常基本上在交易中就被提前发现，如果操作失误，可提前告知相关方修正，如果是系统BUG，就可提前紧急修复，后续再推进根治和架构升级。随着时间推移，影响对账异常范围，虽不能百分百覆盖，但是容易出错的关键点，已经得到有效控制，近几个月，偶发才出现几单（历史用户的存量异常订单引起），对账得到了有效的保护。

经典案例，2023年春节期间，通过预警发现几个异常订单出现，通过排查，是因为基金公司下发可赎回时间为非交易时间引起，涉及16个TA，4000多条记录，假如没提前发现，节后可能会引发批量的异常订单和客诉，形成事故，通过发现处理，规避了发生。

总结

通过这个预警系统，能够提前发现并主动处理对账事后异常，其技术难度并不高，更多的讲究的是一个方法。对此方法起了一个名字叫”先知预警”，也希望此理论能对您的系统有所帮助。例如实战中，今年618的拉新活动渠道的监控，10分钟如果没产生订单就进行电话预警；基金停售提前3天邮件电话预警，都可以用此理论解释。

先知预警：是一种基于时间序列分析和业务理解的预测方法，它通过分析历史数据和理解业务，预测未来可能出现的关键点和变化趋势，并及时进行预警和调整，以确保业务的稳定运行。