监控功能是后台产品中既常用也重要的功能，主要起到异常预警和异常控制的作用。本篇文章主要阐释如何打造监控功能。
01 什么是监控功能？
监控功能是指针对某项数据或某项业务流程进行系统层面的定时扫描和执行控制措施，旨在定位目标数据中的风险或发现业务流程中的问题，并通过系统采取必要的自动化控制手段并沉淀相关数据。
监控功能是后台系统中的轻量级应用，一般较多的涉及数据、逻辑层面，较少的涉及界面原型设计。
02 为什么需要监控功能？
任何公司在运营一段时间以后，都会产生数据，这些数据可能是与业务目标直接相关的核心指标。
对于电商产品而言，是GMV、是利润；对于社交、短视频等c端产品而言，是DAU、MAU。
这些数据一般出现在Dashboard面板上，由于业务部门、产品部门每天都在看，当出现业务指标的数据浮动时，即使不设置针对关键业务指标的监控功能，也一样能很快发现问题。对于核心指标的监控，重点不在于发现问题，而在于快速定位问题的原因，并进行自动化的控制。
而一些隐藏较深的间接数据，是从侧面影响核心数据的，而这个影响可能具有滞后性。如果能在其影响核心数据前，监控间接数据，并及时采取控制措施，那么可以将业务损失降至最低，影响范围降至最小。
03 监控的核心要素
监控的核心要素为监控的对象及其限定条件、监控的时间范围或监控的数量级、系统执行的时间和频次、触发条件、处理机制。
1. 监控对象及其限定条件
如果监控对象是利润，这个数据是系统已有的，也不需要限定条件，直接对利润监控即可。
如：当利润≤0时，这个就是一个明确的监控对象。
如果监控对象是某项复杂业务流程，那必须明确说明选取对象的规则。
如：针对首次充值订单，且充值时间在30分钟以内的所有订单进行监控。
2. 监控的时间范围或数量级
根据不同业务的数据量级不同，选择合适的监控时间范围，对于利润，半小时内已经足以产生波动较大的数据，根据利润的数据波动情况进行数据分析，选择合适的时间范围进行监控，选择最小产生明确利润波动的时间单位。
假设通过数据分析得出该类产品订单量和供货渠道都相当不稳定，10分钟就可能产生利润相差较大的结果。
那么在定义该产品监控时间范围时，选择监控近10分钟的数据。通常这个时间尺度越小，则控制起来风险越小。
以上情况适用于数据在时间分布中是均匀的，那么对于一些数据分布不均匀的业务而言，应该使用累计数量划定监控范围。
比如异常订单，它的出现往往伴随着随机性，出现的时间完全不可控。那么就应该设定：监控近x笔异常订单中，异常问题定义为无状态码的订单。
3. 系统执行的时间和频次
系统执行时间一般有：
设置固定时间点执行；
设置固定的间隔时间执行。
选择1意味着业务流程，可能含有更多人工干涉的因素；或者系统在执行其他程序时与此程序有些不兼容的问题，比如前置条件和后置条件，为防止程序产生冲突，设置固定的时间点执行。
选择2则意味着业务数据在时间分布上是均匀的。
间隔时间的设置跟业务的响应时间成正比，业务越需要快速响应的，执行的频次越高。如利润属于公司核心指标，出现亏损是不可接受的，所以响应时间要尽可能快，间隔时间可设置为5分钟或10分钟执行一次。
即使选择了按照固定频次执行，也不意味着万事大吉。产品人员还需要与技术协商好该程序几点开始执行，执行一次的时间大概是多少秒，执行程序是否会对关联数据产生影响。
4. 触发条件
监控既然是对业务中风险进行控制，那么必然需要有响应的触发条件。
触发条件主要依赖于阈值的设置，通过阈值的灵活设置，可以让业务部门随时根据业务情况自行配置相关阈值。如下图所示：
当达成触发条件时，系统会执行相应程序。
5. 处理机制
处理机制一般为告警和系统自动执行。
（1） 告警按照问题出现的严重程度，采取不同的告警措施：
数据波动幅度较大，情况紧急，设置电话通知的告警方式，保证消息及时收到，业务人员可以及时处理（即使在非工作日遇到紧急情况也能迅速处理）；
数据波动幅度一般，对于时间要求较宽松的，采用短信通知的告警方式，业务人员看到后处理即可；
数据波动较小，处理或不处理影响不大的，或仅做通知用途的，可采用系统推送消息的方式告警。如果是日常运营内容，如工单的处理、审核等（数据量小，频次不高的情况），也可采用系统推送的方式。
当对某项业务数据进行告警时，告警信息务必明清晰告警内容主体，告警相关数据，该主体对应设置的阈值，便于第一时间明确问题出现的层次和范围，查找更深层次的原因并进行控制。
（2） 另外一种处理机制是系统强制执行，控制目标产品下架、强制关闭某功能。
一般为达到止损或减损的目的，通常配合告警信息同步使用，一方面起到通知的作用，另一方面便于后续查找问题。
所有的超过阈值和相关处理措施都应该形成日志记录，如需要后续迭代和分析数据的，则需要形成完整和规范的数据报表，并且需要导出功能。
04 监控的其他辅助功能
1. 主监控页面
主要以表单页面呈现，对于处理需求频次较高的业务，或比较重要的业务，需要设计该页面。
如果监控的产品处理频次低，告警频次低，则不必设计该页面。可根据处理的操作不同区分不同的监控产品，如产品强制下架的划分为一类，产品订单限制的划分为一类，分类方法没有局限，主要根据业务需求。
表单页面设计，必须包含监控主题、统计范围、数据相关阈值、触发动作、详情等，如下图示例：
2. 数据统计功能
监控功能的设计不是一蹴而就的，先设计出基本的功能，然后再凭借数据统计功能分析数据，掌握其中数据的规律，做好下次迭代。
一般针对数据较复杂、设置阈值不清晰、产品需要个性化阈值方案的监控功能。
同样以表单页面进行呈现，数据统计一般根据业务需要，每隔一段时间生成一组数据，字段需要包含监控主体、阈值相关的所有数据（如时长、订单数、统计时间段等）、是否触发动作、统计时间等。
需要导出功能以方便分析，另外数据统计需要和设置阈值的统计频次尽量保持一致。
3. 操作记录功能
不一定所有执行动作都是系统完成的，人工也有可能操作。处于风险管理的需要和追责，需要记录所有操作的操作人，操作人一般为系统和具体人名。字段包含操作内容、操作人、操作时间。
不光是对于产品的操作需要操作人，对于阈值的操作也需要操作人，比如谁调整了相关阈值，这些都是需要记录下来的。
4. 阈值配置功能
阈值配置一般适用于触发条件会随着业务需求变化的情况，这样方便业务操作人员根据业务需求灵活调整阈值配置。或者产品繁多，各个产品都需要配置个性化的阈值方案。
阈值配置也并非一味的追求灵活配置，需要非常清楚这些阈值对业务的影响，部分数据需要可配置的方式，而一些数据固定后台写死比较好，一方面出于风险控制考虑，配置越灵活，越有可能出错；另一方面考虑到开发成本，配置项过多的，开发难度越大。
而一些业务对于时间不敏感的，可以长期使用一套固定的阈值方案，那么可以不设计配置功能。
05 其他注意事项
后台产品核心就是业务，一切都在满足核心业务需求的基础上提高用户体验，原型图不追求高大上，也不能一开始就把原型画的很完善。先出一个简单的功能逻辑、流程图，描述你将要做的功能是什么，先进行内部的业务评审，评审通过后再着手完善原型和文档；
监控类产品的核心在于阈值的设置、监控范畴、统计频次、统计时长、数据敏感度这些抽象逻辑层面，而不是具象化的原型demo，所以事先做好业务需求调研和数据分析非常重要，这样在设计功能时才能有的放矢；
监控类产品不能一开始就追求大而全，先重点解决对业务影响较大的、急需监控的数据，保证核心功能的可用性，再通过数据沉淀分析数据，逐步细化产品需求，并逐渐迭代产品；
后台产品大部分页面都是在设计表单页面，必须清晰明白哪些字段属于核心信息，哪些信息属于不必要信息，精简字段，字段太多也会影响查询效率的。
