由于笔者转行新零售行业，最近负责智能货柜的产品设计，针对智能硬件经常发生的设备故障，怎么去第一时间监控到设备硬件和软件上产生的故障，是当下笔者研究的一个课题，本文就如何搭建故障监控与告警系统进行了浅析与探讨。

一、有关故障监控与告警的基础知识

智能货柜同一般的软件有较大的区别，软件只涉及服务应用层面的交互，而智能货柜则既涉及到软件应用的交互，还涉及到硬件和软件的交互，因此智能货柜的故障和监控要比普通的APP以及系统要更加复杂，下面就故障监控与告警相关的背景和知识做相应的介绍。

1. 什么是故障？

百度百科对于故障的解释如下：

故障是系统不能执行规定功能的状态。通常而言，故障是指系统中部分元器件功能失效而导致整个系统功能恶化的事件。

而对于智能货柜来说，故障即是任何会影响设备正常售卖的事件，包括硬件上的故障，也包括软件上的故障。

• 硬件上的故障包括：锁故障、门故障、制冷故障、货道故障等；
• 而软件上的故障则包括：无法支付、软件死机、卡屏、交易失败等。

故障的种类有可能是非常多的，对于产品而言只能在最开始系统设计的时候，尽可能的穷举出越多的故障，只有明确了故障的种类，才能监控到这些故障。

那我们为什么要做故障监控与告警系统呢？

对于智能货柜来说，每一个运营都需要负责非常多的设备，而不能时时刻刻守在设备旁边，也就无法及时知道设备发生了故障，因此故障监控与告警系统将会产生如下价值：

• 及时性：自动获知机器故障信息，并将故障信息传递给对应的线下运营人员，第一时间解决机器故障，恢复设备售卖；
• 收益性：设备故障无法售卖，自然会降低设备的交易额，而通过故障监控告警，可以最大程度的降低运营的损失，提高机器交易额，也就为公司创造了更大的效益；
• 同时故障监控和告警也会积累大量的数据信息，为产品的迭代和优化提供强有力的支持，提升产品的性能和体验。

2. 监控告警的目标与区别

监控与告警的区别：其实本质上监控是告警的基础，只有具备了监控的信息，才能针对监控的信息去指定相应的规则和策略来进行告警。监控的信息是非常全和杂的，但是对于接受故障的用户来说，杂和全的信息会干扰用户的判断和决策，因此只有在监控信息基础上，针对相应的规则筛选出需要告警的信息来进行触达和展示，才能最大效率和准确的解决相应的故障。

监控和告警的目标则是一致的，即：

• 全面：监控与告警的广度，尽可能多的覆盖到故障类型
• 及时：数据处理和传递的时效性，快速的将告警信息暴露出来
• 准确：保证监控和告警信息的准确性，避免浪费相应的资源去解决错误的告警。

二、如何从0到1搭建故障监控与告警系统

既然是从0到1的系统，那自然不免会涉及到非常多的工作需要去找。前期用户调研、竞品调研以及市场背景都要去了解。

用户调研：因为系统做出来不是给产品用的，因此必须要了解该系统使用对象的想法。一般来说针对公司自己软硬件的故障监控系统，都是给公司内部相关部门的人使用的，因此用户调研上相对来说会比较容易，需要了解使用对象的使用习惯、对于哪些故障类型比较关注，尽可能多的收集故障类型。

竞品调研：一般来说对于陌生的产品和系统，为了避免更少的踩坑，还是需要多多体验市场上存在的产品，包括成熟和不成熟的系统都可以去参考，能够产生许多的灵感。

以上2点是做该系统比较简单的工作，以下内容则涉及到故障监控与告警系统具体的产品设计方案。

1. 故障监控与告警系统的基础

首先要做故障的监控，就必须要了解和清楚怎么去监控设备硬件和软件的相关信息，主要通过如下方式去监控故障：

• 硬件上报：首先在做一款智能货柜的时候，如果是定制化的机器，在机器出厂之前，在硬件上就需要双方协定做好哪些协议和串口，此时需要硬件和软件产品经理共同探讨，在出厂前就需要明确需要监控哪些硬件故障，而为了监控这些故障，必然需要在硬件上做相应的开发。比方说要监控机器的温度，如果机器没有上报温度的串口和协议，那我们必然无法监控到温度异常的故障；
• 软件埋点：软件埋点更多的涉及到前端交互页面的监控，比方说某个按钮的点击率，某些环节的转化率，而只有这些地方埋点后，我们才能监控到这些数据，才能判断是否软件出现异常和故障；
• 服务器与日志上报：服务器和日志更多的是通过后台接口的方式进行监控，比方说某个接口宕机或者高并发挂掉，而后台的故障事先都需要定义好相应的错误码，通过故障错误码来监控故障信息。

只有以上工作做到位后，才能具备监控和告警的基础，不然没有这些信息，后面也没办法实现故障的监控和告警。

2. 故障监控的类型

前期在故障类型较少的时候，有可能是通过开发代码定义故障类型，但是为了后续系统的拓展和兼容性，建议还是通过页面配置的方式来实现故障类型定义。

以下通过智能硬件的故障类型来给大家详细说明，故障类型的编辑可能涉及到如下字段来区分故障：

• 故障id：故障id是唯一的，每个故障都会上报一个故障id，通过故障id可以唯一确定每个故障；
• 故障类型：故障类型其实也是可以通过前端页面自定义创建的，在此可以直接通过下拉选择故障类型，如果要新增故障类型则通过新的页面去操作；
• 故障名称：通过故障id无法直观知道每个故障，通过名称则很直观和清晰的知道每个故障信息；
• 故障等级：故障等级对于故障告警的策略和编辑是非常有用的，此字段也是必要的；
• 推荐解决方案：推荐解决方案是给相应的运维人员查看的，对于一些新运维人员需要通过此信息去指导运维人员去解决相应的故障。

以上字段是对一个故障最基础的编辑和定义，当上报一个故障id时，则可以通过故障id去拉取该故障的其他信息。不同的业务可能对于故障的定义字段都不尽相同，需要根据业务去灵活制定。

3. 故障告警的规则和策略

正如上文提到的，故障监控和告警是两个不同的事情，监控是把所有上报的信息都会记录下来，所以信息一定是多而杂的，这些过多的信息如果都推送给相应的人员，那很可能是大大提高了用户处理错误信息的工作量，所以是需要规则和策略去筛选准确的故障信息进行推送。

那么告警规则和策略包含哪些信息呢？简单粗暴的来说，一个告警规则和策略需要包含告警的统计指标，告警推送的条件、告警的收敛规则。

举例如下：

比方说针对网络故障的告警，则对应的监控项为网络速度，那么创建一个告警规则需要定义如下信息：

• 告警名称：网络故障告警
• 告警指标：网络速度
• 告警条件：网络速度小于20kb/s
• 统计时间：30分钟
• 发生次数：3次

那么当某台设备30分钟内上报网速小于20kb/s大于等于3次时，就需要通过告警推送到对应的人员。告警规则也是可以通过前端页面去灵活配置的，这也大大提高了系统的拓展性和广泛使用性，可以及时跟进数据情况修改和新增相应的告警规则。

4. 故障告警的方式和渠道

当系统监控到需要推送告警信息时，需要通过什么渠道推送告警信息呢？这里也涉及到前期用户调研的一些内容，一定是需要通过最简单、高效的渠道去推送到运维人员手中，主要有以下方式和渠道来进行推送告警信息：

• 告警后台系统：通过数据仓库可视化的告警以及告警列表来推送相应的信息。此种方式是最基础的信息来源，但是运维人员不可能时刻打开后台系统来查看，因此此种方式是比较不适用的不高效的；
• 邮件：一般使用系统的人员有可能是使用电脑的，但是对于智能货柜的用户群体来说，他们经常都不在办公室奔波于线下，如果手机未安装邮箱APP，则无法及时获知告警信息；
• 微信公众号：通过微信公众号的模板消息来进行触达是非常高效的，使用的人员能够及时收到相应的告警信息，而且微信公众号的模板消息是免费的；
• APP推送：APP相较于后台系统还是有效许多的，通过APP消息推送和内部的告警模块进行触达，主要是由于运维人员用的最多的就是APP，需要用到APP补货、查询数据等，所以通过此方式也是非常可行的。

以上列了主要的几种告警推送的方式和渠道，其实还包括一些其他的方式，比方说钉钉群、微信群、短信等，至于需要通过哪种方式去推送告警信息，一般都是需要根据业务来确定，也不一定是只通过一种方式去触达。为了保证告警的效果，可以多种方式同时推送，但是前期也需要平衡开发的成本和收益，选择一种最高效、开发难度最小的进行触达。

三、故障监控和告警系统总结

故障监控和告警系统其实相对来说还是一个比较简单的系统，但是如果需要从0到1的去搭建这样一个系统也是需要注意比较多的情况，尽可能系统化、模块化的去设计这样一个系统。

• 做好充分的用户调研、竞品调研和背景分析，充分挖掘用户的痛点和需求，参考成熟的一些系统方案；
• 前期基础需要搭好，一定要搭建好故障上报的体系，没有渠道去获取相关的故障信息则无法做故障的告警，则后续系统的搭建也是白搭；
• 故障的定义、告警的规则和策略是该系统的核心，需要尽可能多的整理总结故障类型，覆盖多一些故障，其次也需要根据实际情况不断去调整故障告警的规则和策略，优化迭代故障告警的准确率。
• 通过何种渠道去推送告警信息，也是需要根据用户的使用习惯，结合开发实现的难度和成本去综合考量，必要的话可以采取多种方式去推送，以提高故障触达率与解决时效。

作者：harryli，新零售行业产品经理，微信公众号“Harry李先生笔记”。

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

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