业务风险管理角度

从业务风险管理的角度上，一般将风险管理分为事前管理、事中管理、事后管理。

事前管理，目的是预防事情的发生；

事中管理，目的是及时介入，避免事情变得更糟糕；

事后管理，目的是缩小已发生的问题造成的影响面、降低影响程度。

从业务风险的角度，我们能够理解风险告警的目的。

流程类风险，是流程监控中常见的，比如事情应该做而没有做、延迟做了、出现了不应该出现的事情（流程节点）。

总量类风险，是水平监控、质量监控中常见的，比如今天应该完成多少，没有完成；平时正常水平多少，现在监控指标超过了正常水平相当比例。

从产品角度，我们能够区分出我们遇到需求的是哪一类问题。

一个例子 

一家车联网公司，最近想做一个用户疲劳驾驶的风险告警，业务方设想的场景是，如果超过了交通法规规定的时间，就通过车联网APP给用户发出告警。

从风险管理的角度看，这个需求属于是事后管理，因为业务希望是已经发生疲劳驾驶，发出提醒。

从产品角度看，这个需求属于总量类风险（水平监控），当数据积累到一定值，发出告警，这个一定值，是交通法规规定的，所以是一个固定值。

弄清楚这两点，我们的解决方案也大概有了个轮廓，采取策略方法，通过监控持续驾驶时长这个数据指标，当数据指标到达阈值时，触发告警。那么，我们产品方案的核心就是要弄清楚持续驾驶时长这个数据指标的计算逻辑，这个和车联网采集上来的数据是什么样高度相关，数据指标逻辑选取是另一个话题，我们这里不展开了。

用这个例子向大家说明，一个数据相关的风险告警场景的需求分析大致是怎么做的。

表面上看，这个例子不太像BI系统干的活，更像是一个车联网的应用场景。事实上，如果要在一个BI看板里面进行业务决策支持的应用，他要面对的需求场景和解决方案都会更复杂一些。

之前的文章里我们提过，BI系统做数据决策之所以是一个比较难的问题，是因为现实世界存在复杂性。复杂性决定了在做数据赋能和业务决策相关的数据产品设计时，要避免『一刀切』的想法，避免『毕其功于一役』，避免设想自己的设计能够『一次成功』，这是一个不断调优的过程（如果是一名策略产品经理或者算法产品经理，应该能很好理解），调整好心态，我们开始吧。

用数据来做风险告警，大概有这么几种方案：

• 
  

• 数据+策略/规则

• 数据+数据挖掘/机器学习

• 数据+知识图谱

本文从产品角度，给大家介绍需求场景如何与这些解决方案相结合。

这是一个我们通常会遇到的需求描述。表面上看，需求很明确，但仔细一琢磨，就会发现这个描述有很多模糊的地方。

这里面最大的需要明确的点，就是如何定义疑似异常导出的行为，即风险识别。

那么根据不同层次的需求，我们的解决办法有相应的不同：

业务侧说，我们有很明确需要监控的重点表，根据之前的业务case，当发生这些行为的时候（同一天内多次导出不同查询条件的同一个表的数据；同一天内导出总数据量超过xxx条数）就是疑似异常导出。只要先识别出这些行为推送给我们，通过一些日志去判断是否真的是异常就可以。

数据要做的是什么呢？帮助业务方在进行风险识别的时候提升效率、也就是筛选一个大面积的数据集，然后推送给业务人员进一步识别。

设计解决方案

1.确定初步方案

需求到这个程度大致明确了，我们可以使用数据+策略的产品解决方案。即统计每个用户对监控的表的单日导出次数，和每个用户对监控的表的当日单出总量，两者有一项超出阈值（或者同时发生时），将用户信息及操作日志推送给指定的管理员用户。

2.迭代

现在，来看一下迭代需求。对接人反馈，第一期上线后，确实解决了大海捞针的问题，但是现在公司规模扩大了，数据量和数据分析人员增加，现在推送的疑似异常也多了很多，用户已经分析审核不过来了，能不能把风险比较高的给我们，低风险的那些就先给这些用户做一些告警提示。业务对接人还提出来一些想法，比如按照导出次数大小或者按照数据量大小去分这个风险高低，低风险可以等审核人员有空的时候进行抽查。

首先通过判断，这是一个迭代需求，需求还是事后风险管控+水平监控。

然后通过分析，这些新增的内容，是对于告警的精度要求提升了，说白了，就是要降燥。

业务方给的解决方案是：通过对识别出的异常进行分级，不同的级别对应不同的处理办法。怎么判断我们能不能按照业务提出这个解决方案去做呢？

我们从产品发展的角度分析一下：

这个解决方案进行了风险分级处理，不同级别风险，告警方式不同。这个思路肯定没有问题。

3.分级的问题

在再进一步看，如何分级，用什么原则去分级呢？我们发现业务提供的这个分级的策略比较刚性，如果用一个固定的数据指标值，可能会有两个问题：

1.导出数据量和次数与风险阈值的关系，是和表本身存储的内容和数据量有关，也许不同的表阈值是不同的（意味着有巨大的维护规则的工作）。

2. 随着业务规模发展，存储的数据量规模也会变化，即使同一个表，风险告警阈值很容易就会需要变更。

那么这个规则从扩展性来说，阈值不适合使用一个固定的值了，而是一个受到一些影响因素会发生变化的数。

经过一番需求分析，发现业务对接人提供的解决方案思路是ok的，但是细节还需要进一步去设计。那么这次产品迭代的目标是就是需要在数据监控的基础上，动态的去进行风险分级。

有些小伙伴会说，这个时候该算法工程师上啦！应该让算法同学出解决方案了。

我要说，这个时候其实产品的核心逻辑还没思考清楚，算法同学接到需求，只会丢给你一个白眼好嘛！

4.梳理核心逻辑

怎么去梳理这个核心逻辑呢？

我的答案是，要去思考这件事情的本质是什么，抽象出来。我们要理解的事情是---风险告警推送给审核人员，他们到底在审核什么？

带着这个问题和业务人员交流，沟通后发现，审核要找出用户是不是真的出于不好的目的（比如盗取数据）导出数据。那么，我们风险识别，就是去能够识别用户行为的恶意程度，而风险的分级，就是恶意程度的分级。

现在，需求转化成为了一个相对定量的，评估用户在平台进行数据导出或者查询等一系列行为的恶意程度。恶意程度，如何量化？可以从结果去推导，用户操作得到的数据结果整合后，如果这些内容流出，对公司造成损失程度。把恶意程度和损失程度做了一个对等变换，如何看损失程度呢？通过和业务方调研了解到泄露出去的数据，包含的内容以及内容的组合，如果会推算出一些不公开的数据，或者通过单元数据加工可得到一些财务数据，这种就属于损失比较高的了。

原来如此，不同损失程度其实和疑似泄露的数据集的特征有关系。这个数据集不一定是从有一个表导出的，也有可能是好几个表数据组合的。和数据量明细也许不一定高相关（不同特征的权重是不一样的）。

到了这一步，核心逻辑就整理出一个大概轮廓了：找到某个用户一系列操作行为组合出的数据集的特征，与我们的目标值（损失程度较高的数据集）特征，他们的相似程度，相似度越高，风险越高。

5.明确详细方案

现在，产品思路理清楚了，我们可以去和算法同学讨论，使用什么样数据挖掘/机器学习的算法能够达成需求目标。当然，还会遇到算法同学提出的一些别的问题，需要共同讨论再进一步得出更详细的解决方案。

好了，这个例子对于需求分析说的比较详细，通过对需求不断抽丝剥茧，一步一步深入，最后得到一个解决方案。

未来会继续对数据决策相关做探讨，也欢迎大家和我交流。

说明：作者用了一个虚拟的案例，或者说一个思想实验，与实际上数据安全审计的类似场景会有不同的地方，但是解决问题的思路很值得学习和思考。

-END-