在金融或电子商务行业，所有与交易相关的业务都存在巨大的系统风险。

上周的某一天晚上九点多，刚刚下班上地铁，就在企业微信群中收到消息。

• “我们的成交金额见底了，快看看发生了什么？”
• “系统某个接口出现异常，用户无法完成交易，研发正在解决”、
• “问题发生多久了？造成多少损失？”
• “大概一个小时，预计少了两百万交易量。”
• “为什么持续将近一小时才发现解决？”

我工作后在两家公司待过，公司业务和业绩不尽相同，但都遇到过一样的事情——系统异常导致损失。这似乎成了每个公司都必须要经历的事情，甚至有的损失惨重而造成了一系列多米诺效应。

不管是电商行业还是金融行业，凡涉及到交易的业务，其实都会有很大的系统风险。例如，系统或者接口异常导致用户无法完成交易，这对公司来说是交易额的损失。又比如，运营人员操作不当导致被刷单或者薅羊毛，这对公司来说是利润的损失。

当我们聚焦于业务的增长时，往往会遗漏一个关键环节——监控告警。

无论是研发人员、产品人员、运营人员，其实都不能保证任何事情百分百“无bug”，研发接口可能受性能影响等会报错，产品人员可能设计逻辑时会有遗漏，运营人员配置活动时可能会失误。金无足赤，人无完人。但是，当出现问题时，我们需要能最及时的监控告警，最实时的排查解决。

无论是什么公司，什么业务，监控告警都是不可或缺的。

一、需要监控什么？

我们日常监控的内容，大多包含两个层面。

一是研发接口监控。

在很多情况下，流程异常都是接口先报错，进而影响到后续业务，所以接口一般会比业务数据更快的暴露问题。

研发在开发各类接口，尤其是核心流程接口时，大多会有接口监控，例如创建订单接口、订单支付接口等。

研发侧会监控接口报错次数，正常情况下接口会正常运行并返回结果。但当接口报错时，意味着无法正常返回结果，会导致流程阻塞。所以如果接口在某一段时间内，报错数量陡增，那意味着该接口出现异常。该类告警必须为实时监控告警。

二是业务数据监控。

对于产品和运营人员，每天最需要关注的就是业务数据，比如当天的成交用户数，成交GMV等。大多数情况下，我们会T+1去查看并分析前一天的详细数据，毕竟所有业务数据都实时跑，对性能的压力比较大，并非每个公司都有足够的资源和实力。

但是对于部分核心业务数据，需要进行实时监控并预警。例如，下单人数、下单数量、成交人数、成交单数、成交金额等。如果发现在某个时间段内，成交金额突然急剧下滑或者上升，那么很可能是业务出现异常。

针对核心业务指标，我们需要重点观察其变化趋势和极端绝对值。无论是突然同比增长200%，或者变化为0，都是属于异常情况。

综上所述，我们可以监控的内容包括：

• 接口报错监控，实时监控核心接口的报错数量和成功率
• 业务报错监控，实时监控核心业务指标的变化趋势

二、如何监控告警？

如何监控告警，实际上蕴含了三个问题：

1. 针对什么进行告警？

针对什么进行告警，其实在上文需要监控什么中已经有所提交，我们一般需要对研发接口的报错情况和业务数据进行监控并告警。研发接口一般情况下研发系统会有专门的管理和监控，此处我们重点讲针对业务数据的监控和告警。

上文提到，我们需要对核心业务指标进行监控，实际操作中，我们需要明确定义这些指标。

首先，要找到数据来源，研发侧对于数据的上报，是上报到某个数据库实例中的某个数据库的某个数据库表的某个字段，然后业务侧对这个字段通过运算符公式加工为指标。

数据库实例是程序，是位于用户和操作系统之间的一层数据管理软件，是访问数据库的通道；用户对数据库中的数据做任何的操作，包括数据定义、数据查询、数据维护、数据库运行控制等等都是在数据库实例下进行的，应用程序只有通过数据库实例才能和数据库打交道。通常来说一个数据库实例对应一个数据库。

数据库中会存储很多张数据库表，每张数据库表有其应用意义。每张数据库表又会有很多个字段，每个字段对应不同的内容。当我们将数据上报时，意味着将某个数据作为字段值写入到对应字段中。

把字段值通过运算符公式进行加工，就能得到指标。常见的运算符公式包括sum（求和）、count（计数）、avg（平均值）、max（最大值）、min（最小值）等。

举个例子，我们要监控成交金额这一指标。

1）选择数据库实例，例如ec_database_instance

2）选择数据库实例中的数据库，例如ec_order_database

3）选择数据库中的数据库表，例如ec_order_detail

4）选择数据库表中的字段进行加工，形成指标，例如sum（order_amount）

2. 什么情况下进行告警？

我们知道要针对某些数据指标进行告警后，还要知道什么情况下进行告警，此处可以理解为设置告警规则，命中规则的情况下，就启动告警。

如果公司的大数据能力较强，包括数据完善、计算能力较强，可以使用大数据能力分析其合理范围。即大数据会计算某个指标的预估变化范围，如果指标值在该范围内，则表示正常；若指标值超出该范围，则表示数据异常。

在公司数据能力建设还未完备的情况下，我们可以考虑自行设置监控规则。

一个指标的监控，可能是由多条规则组成，我们需要考虑是针对多条规则取交集还是取并集。取交集则表示，同时命中多条规则就会告警。取并集则表示，命中任一一条规则就会告警。

每条具体的规则需要设置对比规则和对比阈值，常见的阈值规则包括：

• 固定值大于/小于X
• 同比昨天同一时间段大于/小于X%
• 环比上一时间段大于/小于X%
• 环比前N个周期的平均值大于/小于X%
• 环比前N个周期的最大值/最小值大于/小于X%

举个例子，我们对十分钟内成交金额进行监控，如果其绝对值小于100，或者同比昨天同一时间段内十分钟交易金额大于10%，则启动告警。如果昨天10:00-10:10成交金额为1000，今天10:00-10:10成交金额为2000，则命中第二条规则，同比金额大于10%（（2000-1000）/1000=100%），命中告警规则。

3. 要怎么告警通知？

当我们针对某个指标设置的告警规则生效后，需要如何通知接受人呢？

这个问题的实质，是我们对告警级别的处理，不同级别的告警有不同的运行频率和通知机制。我们大致可以分为以下三种：

1） 普通告警

普通告警一般为数据变化存在异常，需要产品或者研发进行确认是否存在问题，此时不一定有系统异常，可能是活动等原因造成的波动。

一般为每N个小时运行一次。

通知方式可以是通过企业微信或者钉钉等OA办公软件触达。

2） 紧急告警

紧急告警一般为数据变化异常幅度较大，需要马上确认是否有问题并进行跟进。

一般为每半小时或每小时运行一次。

通知方式除了OA软件触达，还可以通过邮件等方式，尽快告知处理人。

3） 致命告警

致命告警为数据绝对值出现明显异常，需要马上解决问题。例如，交易额突然降为0。

一般为每5分钟或每10分钟运行一次。

通知方式除了OA软件和邮件，还需要加上电话通知。当系统出现异常时，自动拨打电话或发送短信至处理人。

三、怎么搭建监控告警系统？

对于产品经理而言，知道如何进行监控告警后，还需要有对应的系统承接需求。现在市场上很多BI工具其实就有相关功能，除了帮助业务人员展示数据、分析数据外，也会提供监控告警功能，支持业务人员配置使用。

如果公司没有采购外部BI工具，而是选择自行开发的话，那就需要一套监控告警系统。

1. 配置告警指标

配置一项告警指标，有数据来源、维度、有指标、有筛选条件，就好像写一段sql，包括select、from、where、group by。

（1）数据来源

实例、数据库、数据库表：即中间表信息。选择数据上报到的数据库实例、数据库和数据库表。此处一般只支持选择，而不允许输入。

（2）维度

配置查询数据时的维度字段，即sql中的group by字段，可按照实际需求配置多个维度字段，或者不配置维度字段。

（3）指标

配置查询数据时的数据指标，即sql中的select字段，其中指标值内支持常用的计算函数，比如count、sum等，如果对应的字段无需进行计算，可直接填写字段名称

（4） 筛选条件

配置查询数据时的过滤条件，即sql中的where字段。此处一般会提供字段值对应的计算公式，比如某个字段的字段值等于或者包含某些内容，形成一个筛选条件。

2. 配置告警规则

配置告警条件，满足规则的数据将会被视为告警数据进行通知。

• 告警规则：配置满足告警的条件，可按需进行对比类型、对比方式等配置。
• 运行频率：告警任务的执行频率，按需配置。
• 时间维度：告警任务是按照运行频率查询某个时间区间内的数据，此处指定了所选择的数据库表中对应的时间字段。

3. 配置告警通知

产生告警数据后，如何通知到相关的责任人进行处理。

• 告警级别：包括【普通告警】、【紧急告警】、【致命告警】。
• 通知时间：在此区间内的告警数据才会通知，否则不会进行通知。
• 提醒间隔：通知的频率限制。
• 告警方式：支持多选，包括企业微信、邮件、电话等。
• 告警处理人：接收告警通知，并有告警处理的权限。

4. 记录告警处理

收到告警通知后，可在系统查看待处理的告警并进行处理。针对每项告警，可判断为有效告警还是无效告警，并选择对应的问题原因和解决方案。

通过记录告警处理，一方面可以追溯告警的有效性和准确性，便于持续迭代优化告警系统的功能。一方面可以确保每次告警处理结果有迹可循，方便业务侧追踪问题原因和解决方案。

日常的监控和预警必然重要，但我们也需要知道，无论是研发接口的告警，还是业务数据的异常，都是问题呈现到了用户端才被我们发现。实际上，有很多问题也许在管理端，研发人员操作或者运营人员配置时就可以体现。例如，我们监控到成交金额暴增，可能是被用户刷单薅羊毛了，那么在运营人员配置运营活动时，是否可以先计算相关金额并提醒其配置的准确性。尽可能的将问题前置暴露并及时解决，才是根源所在。

每年9月份开始都是各大公司的“体检季”，别忘了给公司业务和系统也体检一下，有很多赶紧“告警”！

作者：球溜溜，微信公众号：产品小球

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

题图来自 Unsplash，基于CC0协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。