笔者在最近的日常工作中发现，公司内无人设备的故障报警和维护长期没有形成完整的业务闭环，一线运维人员效率低下，也对用户体验造成了一定的负面影响。 为此，笔者对行业内的相关产品进行了研究，同时对相关业务员的需求进行了调查，最终初步形成了运维故障报警平台。

01 引入概念

1. 什么是告警？

着急的战斗机，即系统发生故障时，监控单元根据指定的报警策略，通过预定的推送路径，向指定的接收者(服务端、客户端)发送报警通知

2. 什么是无人设备的故障告警闭环？

具体如下图所示。

机器端：设备通过工程，将出发的软件或硬件故障同步到监控平台(服务端)服务端：监控平台经过一系列的报警策略，将报警消息推送到承运人(客户端) 客户：承运人收到警告通知后，在设备点维护设备； 机器方面：设备维修完毕，更新设备状态上传到服务器方面。

02 用户画像和需求

1. 用户A

张先生，男，25岁，一线运输工作人员

负责xx分公司xx线路的设备故障维护。 由于部下负责的区域很大，所以区域内无人设备数量多，随之而来的故障也很多。 张先生故障的接收仍然依赖于设备现场地方工作人员的投诉、客户工作人员的邮件、补充人员的信息的同步。

有故障报警推送服务，我想实时通知他哪个设备有故障需要维护，哪个报警优先级高又紧急。 这项推送服务将大大提高他的日常工作效率。

2. 用户B

细心的枫叶，男性，30岁，总部项目运营负责人

负责总公司xx无人设备产品的在线运营。 由于工作压力和责任大，每天需要整体了解全国设备的运行情况，但目前掌握设备运行状态的手段还停留在初期阶段，需要每天让下属收集数据，过程繁琐，同时效率低，时间成本高。

我想要一个能够随时掌握全国无人设备运营状况、故障状况、报警处理状况的实时故障监测平台。

在调查了

03 功能结构组成

行业内的产品和用户需求后，笔者将运维故障报警平台的组成分为以下几个部分。

故障数据故障监测故障报警处理设备健康度评价

关于

1. 故障数据

故障数据，笔者建议可以从以下步骤着手。

故障数据分类故障数据存储故障数据的筛选和过滤故障数据仓库的产品化

故障分类：行业内对无人设备故障的分类大多较为成熟，具体实例如下。

针对不同类型的故障，制定明确的警告策略，用于触发和推送警告。

故障数据存储：根据无人值守设备软硬件的基础设计，提前建立与公司业务需求相对一致的存储字段，包括设备编号、故障名称、故障代码、故障开始时间、恢复时间、持续时间、故障次数等； 关于数据存储的逻辑，不同产品的业务差异很大，所以笔者不做过多说明；

故障数据的筛选和过滤：人为过滤不影响无人设备正常交易的故障，或者承运人在货物补货和维护故障时发生的干扰性故障

好处包括：

减少干扰性故障，聚焦关键故障； 降低运维人员关注成本，提高生产效率数据仓库产品化：将各种故障以一定形式保存在产品化仓库中，便于后期的及时更新和维护，以数据仓库为中心的产品设计：

的展示方式如上。 以故障代码、故障名称、故障类型、警告指标、紧急度释放方案的形式进行维护，产品的功能设计中予以支持。

添加故障； 故障查询； 故障编辑； 警告指标的增加当然，故障代码的增加依赖于设备最初在软硬件水平上的基础设计，有兴趣的学生可以进行更深层次的研究和学习，笔者不做详细介绍；

“单一故障”和“警告指标”的对应关系将在以下故障警告中详细说明。

结合

2. 故障监控

实际业务和需求，笔者将其分为故障日志监测、故障报警监测；

故障日志监控：以一个故障为最小粒度实时监控和记录一个设备

故障报警监控：以一个报警任务为小粒度，记录一个设备的实时状态和维护进度，在承运人维护完毕后，使报警任务和设备的状态同步。

围绕故障监测的相关概念设计如下：

监视故障日志

单个设备-将列表实时显示为单个故障代码

展示，功能上实现一定字段的查询、筛选和导出。

故障告警监控

通过“单台设备—单个告警”的形式进行列表展示，单个告警可包含多条故障，最终以告警任务的状态作为闭环监控的最后关键节点。功能设计上实现一定字段的查询、筛选和导出，同时对单台无人设备的告警任务，提供任务内详情查看（如告警任务领取时间、告警任务领取人员等信息）。

3. 故障告警

行业内对于“故障告警”在产品层面有多种实现方式，笔者在研究了多个产品并调研了业务需求后，将故障告警理解为故障告警策略，并将之拆分为如下几个组成部分：

故障告警策略 = 告警名称 + 告警对象 + 告警指标 + 触发条件 + 消息推送；

告警名称：即整条告警指标的名称，比如告警指标-“温度异常”，可命名为xx设备温度过高告警；

告警对象：即该告警对哪些设备有效，在无人零售行业，该类设备大多为饮料机、弹簧机、挂钩机、综合机、无人货架、无人货柜等；

告警指标：即对某一个或某一类故障统一指定的告警名称，该处设计在产品层面体现在将多个同类的故障归类为单一的告警指标；比方说，温度过低&温度过高，实际为两条故障码，但可以人为将之合并为一条告警指标—“温度异常”；该设计的优势在于，一线的运维工作者不用针对一类故障去逐一对接和记忆故障码和故障名称，取而代之的是仅记忆一条告警指标即可；

触发条件：指触发告警任务生成的的条件，笔者根据实际业务将触发条件大致分为如下三类：

消息推送：指通过一定的渠道，将消息推送到相关权限人员的手机客户端中；

围绕上述几个组成部分，开展产品设计，原则为：配置规则简单灵活，自定义指标值，自定义触发条件，自定义消息推送渠道。

进入告警配置列表：实现多字段查询和筛选、新增告警、编辑告警、关闭和启用告警。

新增告警配置：输入告警名称，选择对应的告警对象，告警指标可自由选择，触发条件为笔者结合实际业务需求后制定的初步方案，基本覆盖所有的告警指标并支持自定义值；

消息推送默认为内部app友智慧，运维人员可通过手机客户端实时接收告警推送消息。此处笔者不建议各位同学们使用平台消息推送，因为B端平台网页的自动刷新会给服务器带来一定的负荷，但手动刷新对人的要求较高，所以不推荐；邮件推送的方式可根据实际情况选用。

4. 告警处理

即一线运维人员通过手机客户端接收告警消息并领取，直到在设备点位处维护完成的过程，该过程为故障告警闭环的重要一环；

告警处理分为：告警消息接收 + 告警任务领取 + 机器端故障维护和清除。

告警处理的设计原则为：消息展示清晰、消息内容简单易懂、告警任务领取方便、机器端告警清除方便。之所以将告警清除放在机器端是为了在一定程度上防止人员操作的漏洞…（此处省略100个字）；

围绕上述原则，开展产品设计：

首先为运维人员手机端

提供告警任务清单和优先级排序（优先级排序根据业务不同，策略逻辑差异较大，此处笔者就跳过了），同时告警详情中对单台无人设备下的多个告警任务可进行自由接取，并支持批量接取，接取任务后同步接取信息至服务器。

此处笔者将告警任务设计为了抢单式，而非传统的派单式，对于抢单式vs派单式的优缺点，有兴趣的同学可作深度研究，此处笔者就省略1000字了～

最后为机器端

运维人员在设备维护完成后，通过无人设备的屏幕进入维护界面，清除相应的告警，此时告警完成，完成情况同步至后台服务器，整个运维故障告警闭环即宣告完成。

总结

在整个告警闭环的设计中，通过明确告警即制定告警策略，针对告警策略进行拆解，同时结合真实的业务场景需求制定了匹配业务的告警触发条件，最终形成有效的告警推送并由客户端接收和落地执行。

此外，平台仍能针对几个方面进行持续性的优化：

更简单快捷的告警配置方式；更加细分的告警对象来提升告警的精准度；更加符合业务目标的告警触发条件。

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

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