自动化识别业务风险，微财业务趋势感知平台 Sparta 的探索与实践

本文主要介绍好分期自主研发的业务趋势感知平台-Sparta。系统的设计目标是通过对业务数据的监控提升好分期的线上问题的感知能力，快速发现和解决线上异常问题，此外还可以通过自动化数据分析能力以及可视化能力及时发现线上业务瓶颈、潜在风险和改进依据，以帮助好分期进一步提升业务效率和服务质量。内容主要包含应用背景、方案设计、最佳实践以及部分代表性的问题的突破等，希望通过本文的分享，为有相关诉求的团队提供一定的思路参考。

业务趋势感知平台-Sparta

1．概述

微服务架构下，开发团队根据业务属性进行拆分，并将系统划分为多个独立的微服务模块，这种拆分可以提高开发团队的自治性和灵活性，还能够实现系统的可伸缩性，从而提高整体系统的性能和容量。然而，微服务架构下的这种拆分方式也带来了一些新的挑战。由于每个微服务都有明确定义的边界，并由独立的团队负责，各个团队往往倾向于建立与其负责系统相关的监控指标。这样做可以确保每个团队对自己的服务有充分的了解和掌控，但也导致了上下游服务之间的监控数据难以串联。当系统出现异常或性能问题时，仅仅依靠单个微服务的监控数据往往无法确定问题的根源。这时需要将涉及的多个微服务的监控数据进行综合分析，才能全面了解系统的整体状态并定位问题。然而，由于各个微服务之间的差异化监控，使得串联分析变得异加困难。

同时，对于很多企业的线上业务是具备一定趋势变化规律的，那么如何在实点数据（用户使用量、短信触达量、app 点击量等）与历史一段时间样本数据同时点对比出现差异时主动进行预警发现，针对业务突发变化时做到主动预警，排除潜在的业务风险？单纯的依靠系统报警等，无法对差异变化进行判断。随着企业线上业务开展的规模和复杂性不断增加，单纯依靠人工分析和报警往往无法及时发现和应对业务风险。

为了解决以上两大核心问题，好分期自主研发了业务趋势感知平台-Sparta。Sparta 采用了代码零侵入的监控数据源上报的设计思想，将常用数据组件进行了兼容打通，并且支持三方定制化数据接入，通过 post 协议将异常数据进行推送收集。通过通用化数据源的接入，基本覆盖了企业的常用系统数据存储组件，降低了使用人员的接入成本，提升监控服务的通用性和易用性以及监控的覆盖范围。

Sparta 通过收集数据后，提供数据可视化监控能力供使用者可以轻易的找到业务数据的变化规律，为运营和用户行为分析提供数据参考；并通过算法排除干扰因素，生成历史样本指标，同时以样本指标为基准实时计算采集的数据偏移量，当业务数据的变化偏移量持续超出或者低于阈值时，通过多样性的报警通知方式相关的技术、运营人员。 

以下为业务数据激增、骤降异常场景的实时数据可视化能力展示：

实时数据统计示例

2．Sparta 在好分期的应用背景

我们选择自研 Sparta 业务数据监控系统有以下几方面的考虑：

2.1.业务监控项过于分散，无法串联分析问题

好分期在 Sparta 应用之前，已有的监控系统支持对系统软硬件环境多维度全方面的指标监控，如 CPU 负载、磁盘使用率、内存使用率、网络流量、服务运行状态等指标，但是各个职能系统的监控相互隔离，而且监控维度、方式、数据不统一，无法进行关联分析，出现问题时，经常需要各个部门参与才能定位问题。为了提升公司的整体问题发现能力，需要一套快速接入的统一监控平台，能通过异常指标相互关联，将不同系统的相同业务指标进行级联分析、溯源。

2.2.缺少直观实时数据参考，业务变化无法感知

好分期在 Sparta 应用之前，因缺少历史样本对比机制，无法及时了解业务数据的变化差异，很难发现潜在的线上问题。例如：某个系统模块发生问题时可能会产生业务指标的变化，或是合作方因为调整内部策略，导致业务指标拒绝率/通过率激增等；并且没有直观实时的数据参考和历史样本的偏差比对分析，企业无法在第一时间感知到这种非阻塞问题带来的影响，延长了该类问题的持续时间。

2.3.业界暂无类似的开源项目方案

当前社区已有的开源监控项目、以及相关的监控服务主要监控的是系统运行软、硬件环境的相关指标，该类系统主要针对的是服务具体的运行状态指标监控，却缺少针对业务数据趋势并对比的监控方案，无法满足好分期数据可视化、自动化监控报警的业务需要，也就意味着无法快速引进与落地，需要自行设计与实现。

3．Sparta 的设计与实现

3.1.Sparta 架构设计

整体架构图

3.1.1.系统划分

• 监控配置 Admin 模块：负责相关任务收集参数、报警阈值规则配置、Grafana 面板参数，并通过 API 发送 Grafana 面板修改指令

• 监控收集 Collector 模块：并行从目标数据源获取数据，并存储至 InfluxDB 中

• 监控报警 Checker 模块：通过规则检查计算出需要报警的记录，报警过程中支持沉默、抑制、聚合能力

3.1.2.具体工作流程

• 管理员通过 Admin 模块发布相关数据配置，保存配置至 MySQL 中，并通过 API 发送面板配置至 Grafana 中

• XXL-JOB 任务调度至 Collector 模块，Collector 从 MySQL 中读取任务收集配置，并行的从目标数据源中收集相关数据，并将收集的数据存储至 InfluxDB 中

• XXL-JOB 任务调度至 Checker 模块，Checker 从 MySQL 中读取报警阈值规则配置，并使用 InfluxDB 的查询语句检查样本和实时数据的偏差是否超过阈值，并判断是否需要发出系统预警，如果需要预警则通过预警渠道发出告警通知相关人员

• 相关人员通过 Grafana 的可视化能力展示 InfluxDB 中存储的实时数据与样本数据走势

3.2.Sparta 业务监控系统设计思路

Sparta 业务监控分为数据收集，数据存储，数据处理，数据分析，数据可视化这五个部分进行阐述，同时也是 Sparta 系统的设计思路。

3.2.1.数据的收集

系统将收集目标定义为数据源，数据源可以是任意数据库，例如可以是 MySQL、Mongo、Redis、Hive、influxDB、ElasticSearch 等数据存储服务等数据库，同时收集目标也可以是 HTTP 方式请求得到的数据结果。

收集的内容只需要是一个具体的统计数据值，例如 MySQL 中的 count，sum 等函数进行统计得到的结果，同时针对不同的收集目标取值可以通过特定的方式适配处理，例如 HTTP 支持从返回的 JSON 中取出特定数据字段作为统计结果收集，如 MongoDB 支持从特定字段中提取数据。

同时将收集的请求定义为指令，不同的收集目标可以使用不同的指令处理器，例如针对 MySQL，Oracle 使用的是 SQL 查询语句，而针对 MongoDB 使用的是 JSON 语句，HTTP 请求则是一个 URL 地址。

与此同时系统还需要内置一些特殊的变量，也就是占位符，如当前执行时间，开始时间（系统约定开始时间=执行时间-跨步间隔）等，这些占位符主要用于请求指令的格式化替换，简化指令中对于时间的函数式计算，同时指令的格式化也支持一部分函数方法，如加减乘除等函数方法。

3.2.2.数据的存储

监控系统关注的核心数据为统计值与统计值发生的时间点，特别适用于时序数据库 TSDB 进行存储，时序数据库是用于管理时间序列数据的专业化数据库，针对时间序列数据的存储、查询和展现进行了专门的优化，从而获得极高的数据压缩比、极优的查询性能。

3.2.3.数据的处理

对于数据处理，使用近 7 天的历史数据作为数据样本，同时还需要对样本进行数据优化，采用基于 Z-Score 的 “去极值”算法实时计算，剔除 7 天内实点数据的最大、最小极值，通过算法修正历史样本的可靠性。

去极值算法示例

具体步骤如下：

• 计算均值（mean）和标准差（standard deviation）。

• 计算 Z-Score：Z = (x - mean) / standard deviation，其中 x 是数据点。

• 定义阈值：通常，Z-Score 超过 2 或 3 被视为异常值。

• 标记异常值：如果 Z-Score 超过阈值，则将数据点标记为异常值。

3.2.4.数据的分析

数据的分析阶段考虑使用阈值预警，即对监控的数据指标进行预设阈值规则组，我们实现了最常用的两种差异分析标准阈值类型：绝对值、比例，当系统检查到实时数据与样本数据之间的偏差偏离阈值一定比例或绝对值时，系统发出预警，预警通道同样支持了企业内部大多数的通信方式：企业微信，邮箱，短信，语音电话等方式（报警通道），用来针对不同级别的差异预警进行不同强度的提醒功能。

• 告警沉默

阈值规则的设置需要支持沉默功能，沉默功能是用来阻止一段时间内符合特定规则的告警通知，例如某个时间段内，某个测试集群在维护，会产生一些预期内的告警，此时因为这些告警是在预期之内的，因此没有通知的必要，那么就可以通过配置沉默规则来阻止通知的发送，即对于检查规则生效时间范围的控制。

告警规则配置

• 告警抑制

同时为了避免短时间内指标异常又恢复的情况，增加业务兼容度，减少报警频次，还需要支持预警抑制功能，即对于短时间内能立马恢复的预警是可以忽略的，例如某个时间段内网络发生 5s 的抖动，但是又立马恢复了，对于这种情况是需要系统自动解除故障的，因此需要在告警检查的过程中降低故障判断敏感率，比如说可以延长持续时间，即持续时间内发生异常才需要进行告警。 

告警抑制配置

• 级联告警

同时由于上下游数据具有一定的流向，上下游业务数据指标的变化趋势具有一定的联动性，因此可以对异常指标进行级联分析告警，溯源异常问题的发生来源；当业务数据指标发出告警之前，规则引擎需要对当前系统收集到的全部告警信息进行聚合关联分析，通过预设的指标分组关联链路关系进行异常数据聚合，形成关联告警链路。

4．实践过程中的部分代表性问题

4.1.InfluxDB 不支持复杂子查询语法，无法聚合计算

在实践过程中，发现 InfluxDB 并不支持使用复杂的子查询语法，无法对近 N 天的历史数据进行聚合计算，于是转变思路改用手动的方式生成数据样本，提出滑动窗口式冗余存储方案，即将某个时间点的实时数据往后冗余存储 N 天，同时需要对存储的数据打上对应的 tag 以防止因为唯一性被覆盖，算法如下所示：

滑动窗口样本算法说明

例如时间点 2023-12-04 10:00:00 收集到数据为 10，2023-12-05 10:00:00 收集到数据为 20，生成的数据如下所示，以此类推生成近 N 天的历史样本数据：

滑动窗口样本计算示意

4.2.收集出现长耗时导致整个采集不可用

在开发验证过程中曾遇到某个数据源数据收集出现慢 SQL，导致整个数据收集功能不可用，影响了后续任务的调度，而 Go 语言天生的并发能力可以很方便的处理这个问题，使用 select 函数的超时打断功能即可实现。该机制可以作为强制长耗时 sql 中断的技术兜底策略，也能将 Sparta 的监控任务配置完全开放给整个团队使用，而无需针对每个监控任务再次进行执行效率等问题的核验工作，避免慢 SQL 对数据库带来的性能损耗。具体实现如下所示：

ctx := context.Background()done := make(chan bool, 1)// 执行耗时任务go func(ctx context.Context) {// 延迟调用匿名函数 (匿名函数在主函数结束之前最后调用，可以捕获主函数中的异常)defer func() {if errInfo := recover(); errInfo != nil {// 执行发生异常处理done <- true}}()// 正常执行处理，结束以后设置chan标记位done <- true}(ctx)select {case <-done:// 正常执行结束处理case <-time.After(25 * time.Second):// 超时处理}

4.3.报警失败，以及过频骚扰问题

在实际应用过程中，报警渠道发送通知并非一定成功，如短信下达率并非百分百，因此需要有渠道补充功能，即当首选的渠道告警发送失败时能够自动降级到其他备用报警渠道；同时，重复的报警内容容易产生骚扰，需要针对告警的频率做限定，如延长同一告警的发送间隔，以及在短时间内不得重复发送相同的告警消息，避免造成骚扰；并且需要支持一定的策略，能够忽略短时间的数据异常波动情况的出现。

4.4.InfluxDB 集群功能不再开源

目前社区已有多个项目在跟进，可以选择相对成熟的方案，如 InfluxDB-Cluster、Influx-Proxy。Influx-Proxy 是一个基于高可用、一致性哈希的 InfluxDB 集群代理服务，实现了 InfluxDB 高可用集群的部署方案，具有动态扩/缩容、故障恢复、数据同步等能力，目前 Influx-Proxy 已适配 Influx-V2。

连接到 Influx Proxy 和连接原生的 InfluxDB 数据库并没有显著区别，对上层客户端是透明的，上层应用可以像使用单机的 InfluxDB 一样使用，Influx Proxy 会对请求进行转发，并对各个 InfluxDB 集群节点进行管理。Influx Proxy 是基于饿了么开源的 Influx-Proxy，并进一步开发和优化，支持了更多的特性，移除了 Python、Redis 依赖，解决了受限于一个数据库、需要额外配置 KEYMAPS、数据负载不均衡的问题。

Influx-Proxy架构图

5．总结

好分期发展迅速，内部系统的架构也是愈加复杂，近百个不同职能系统组共同支撑好分期的金融业务。同时也是因为架构复杂，任何系统的异常波动、合作机构网络、业务异常都会对整体的业务造成影响。Sparta 的建立，提供了一套只依赖各端的数据收集即可完成逻辑串联分析系统化的监控，将监控与复杂的系统架构和业务场景进行分离的解决方案。为业务、运营、技术、运维等多种角色提供了更灵活的监控接入的方案，对于业务变化趋势、异常数量、组件重点指标等多种维度进行覆盖分析，对异常结果进行敏感监控报警通知，为建设好分期更稳定的金融业务体系提供了有力的技术保障。