数据模型的算法与配置（一个实用的规则配置模型）

导读：在系统设计中，经常会遇到需要进行通用规则配置的场景，需要基于一些基础参数进行配置，如类型业务，城市，金额，风险级别等，多个参数组合配置不同的规则或策略，常见场景如业务预警、系统分单、资金排队、模型配置、卡券分发等。此时就需要进行通用配置，并且可以随时调整配置的设计方式。本文介绍一套比较实用的规则配置模型。

通俗地说，规则配置无非是确定要配什么，怎么找到应用对象，找到后要执行什么动作，怎么应用这几个动作。整体思路如下：

第一步：要配置什么事件或功能

搞清楚配置的标的，就是成功的一半。在做规则配置前，需要先把要配置的标的抽象出来，做成通用配置。如业务预警，需要先把预警的事件定义出来。系统分单，需要先把功能菜单定义出来。

那么如何抽象标准化事件呢，需要从系统中抽取，如定义事件的开始节点、结束节点，或者通过编码开发，这里不做展开。

配置的第一步，先选择需要配置的事件或功能。根据配置需要，事件可做成单选或多选。

第二步：什么样的单据需要进来—维度配置

配置的目的是落到具体的产品或者单据上面，而系统中的产品或单据往往具有多个属性，并且要求根据多个属性综合配置。

维度（属性）定义：这里需要先将这多个维度抽象出来，这里需要定义属性名称、属性编号、属性值。前提条件是配置标的（单据、产品）具有这些属性，而且在规则应用的时点属性值是明确的。

维度配置：维度可多选，属性值可多选

多维度交叉，实际上就是一张多联表格，可视化页面如下图所示。

（图片来源google analytics）

第三步：这些标的需要执行哪些动作—动作配置

前两步已经将特定类型的标的选择出来了，接下来是对其设置动作，要它们跑哪个规则。常见的动作类型包括：应用时效、设置金额、控制流程调整、触发预警、触发消息推送、风险标记等。

动作库：这些动作可以通过动作库统一维护，动作类型 动作值设置，动作需要预先编码实现。

动作配置：动作可以单个或多个组合触发。动作的表现需要与系统已有的功能联动，如预警动作对应预警机制，包括预警列表、预警监控、预警解除等。

第四步：哪些规则优先—规则设置

一般需要配置规则启用状态和规则优先级。

规则优先级：在规则配置中，往往会有颗粒度差异，既存在多个维度交叉的精细化配置，也存在单维度的通用型配置，如单独配置某城市某业务类型的规则，与配置全国通用型规则，就是不同的颗粒度。同时配置的情况下，一个单据事件匹配规则时，就会匹配到多条规则。但应用上诉求往往是跑一条规则。这里就需要进行优先级设置。这里有几种设置方法。一是设置规则匹配逻辑，如复杂规则（指维度多的）优先；二是直接设置多个子规则的优先级，如拖拽排序，从左到右命中一条后停止匹配。后者实现起来更简单快捷。

除了规则优先级设置外，还有规则状态设置，即规则的启用禁用。

第五步：规则监控及调优

事件监控：

规则建立并启用后，那么在对应的事件或者单据到对应的节点时，就会主动匹配应用哪条规则，跑出什么样的结果。如当某业务流程做完上一节点时，此时需规定下一节点在多长时限内完成。此时可以建立规则监测表，观察每个事件或单据匹配到的规则及运行情况，如下图所示为预警事件监控表。按每个事件为维度横向分列对应事件记录。

数据面板：

居于规则运行的结果，通过可视化面板的方式展示，可从宏观周期尺度上观察规则运行的结果，并对具体业务进行效果调优。如居于数据面板长周期观察，发现某城市的某业务经常无法在规定的时限内完成，此时就可以人工介入了解实际情况，分析问题原因，看是否需要调整规则参数。

总结：

至此，整个规则配置及应用链路就介绍完啦。其实整个配置并不复杂，核心思路是找到定义好配置标的，找到它并给它配置对应的运行规则。实际应用中，不同场景需要用到的配置维度及颗粒度不同，根据实际需要取舍即可。功能是为了实现业务目的而做，先厘清业务场景再进行场景设计。个人经验总结，希望能帮到大家。

本文由 @摘星 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议

,