个要点细数端端监控体系设计

　　本文总结归纳了B端或G端监控体系设计中的设计要点，并围绕基础信息模块、规则、预警操作、预警问题、监控报表等内容展开。
　　B端或G端的监控，不同于那些面向不同客户群体的C端信贷风控体系，更多的是针对组织内部，或者是同一个体系内的，所以监控的有效性更多是依赖于规则的有效性，依赖于规则引擎的能力。
　　一套完整的B端或G端（下同）的监控体系设计应该是包含基础信息模块、规则配置、预警操作、预警问题反馈、监控报表。从事前、事中、事后整个体系去管理监控，形成一个完整的闭环。
　　一、基础信息模块
　　基础信息模块，作为一个辅助规则的存在，主要在于黑白名单的维护、预警关键词的维护。
　　黑白名单
　　黑名单、顾名思义，就是说，虽然满足或不满足的所有的规则，但是只要是黑名单，系统的会直接阻止其进行下一步的操作。比如说一个给供应商，如果前期因为供应商信用不好、经营不好，被拉入了黑名单，那么所有给供应商付款啥的操作是阻止的。
　　白名单，相反的，虽然触犯了预警的规则，但是系统是放行的，比如说申请报销，虽然按照报销的流程是有金额的限制，但是由于被列入了白名单，规则是不被触发的。
　　关键词
　　预警关键词也是为了辅助的规则的存在，比如说在申请报销的时候，报销的摘要中如果存在洗浴、KTV啥的，系统可以设置相应的规则进行预警。
　　宽表字段的管理
　　宽表的字段的存在，主要是为了支撑事后规则配置，从数据平台中或者数据集市取数的需要，可以对字段的排序、字段的显示名称、是否显示等进行设置。
　　二、规则配置
　　规则配置主要是对规则的基本信息如规则名称、规则类别、预警级别、处理方式、监控方式、规则描述、函数设置等进行维护。
　　图1规则配置的流程
　　注：埋点类的规则才需要规则挂接
　　其中处理方式可以分为阻止、冻结、提醒、提示等；监控方式可以分为事前预警、事中监控、事后分析，那么各代表的含义是啥呢？
　　事前预警
　　是指对监控对象明显的违规行为进行提前拦截、预警。
　　事中监控
　　是指对监控对象存在的疑似违规行为进行拦截预警、如触发规则之后，冻结该项业务或操作、或者上传一些说明材料啥的，让流程继续走。
　　事后分析
　　是指对监控对象的疑似违规行为进行统计，便于事后跟踪统计分析，或者进行分发处理。
　　以上三种监控方式，对应的处理逻辑是不一样的，比如事前事中类预警，需要通过挂接埋点实现强校验；事中监控需要人工的介入，可能需要工作流的支撑，比如督办类规则；而事后分析类的规则，需要通过底层的数据平台来进行处理，下面对以上几种情况进行详细的描述。
　　1. 事前事中埋点类规则
　　图2 事前事中埋点类规则处理
　　事前事中埋点类规则，一般分为业务类校验、监控类校验；对于业务类校验，在触发规则之后，事件是不写入业务系统的数据库中，是不带BID的，那么对于这类的数据记录，更多的是需要靠监控系统自身产生Bid进行记录。
　　而对于监控类的校验、触发规则之后，业务系统也是会触发规则的，但是唯一的区别的是，监控类的校验，预警的数据是写入了业务库中，是带有Bid的。
　　事前事中类规则，往往是通过埋点的实现形式，那么规则的配置常常需要依赖于规则引擎的实现，所以设计一个好的规则引擎就显得至关重要。
　　2. 事后类规则
　　事后类规则，由于更多的是为了进行事后的数据分析，为便于规则的扩展往往采用的是数据平台。数据平台通过ODS库、调度中心等实现定时的抽取数据，进行预警分析。
　　图3事后类规则处理
　　如流程图中所示，监控平台产生的预警处理结果，依赖于数据平台的数据仓库、自助取数，形成固化的脚本，通过调度中心来实现规则的计算。
　　3. 业务督办类规则
　　督办类规则主要是针对超时任务的处理，可以催办处理，主要表现为超时设置、超时数据 监听、催办操作、监听更新操作。
　　三、预警操作
　　预警操作，主要是针对触发了预警规则的数据进行操作，比如冻结的数据，需要重新解冻，让流程继续走下去。
　　比如监控对象针对预警，上传了说明，让流程继续流转之后，所产生的材料需要去审批。
　　以及触发的预警，是否需要监控对象进一步的处理，在预警操作这里进行处理，作为日常的监控工作。
　　四、预警问题反馈
　　对于B端或G端的客户来说，由于监控对象更多的是组织内部，所以往往需要设置一个预警问题反馈，主要是对于一些高频的预警操作，进行相应的整改，以防止后续持续触发的预警，以及对预警反馈的整改材料进行存档啥的。
　　五、监控报表
　　对于所有的预警数据，都应进行存档、便于后续的可查可视，预警的监控数据，可以按照预警级别、预警规则进行，也可以按照月份进行统计。