无人零售产品：如何从0-1搭建运维故障告警平台？
01 引入概念
1. 什么是告警？
顾名思义，即系统发生故障时，监控单元根据指定的告警策略，通过提前确定好的推送渠道，将告警通知推送给指定的接收方（服务端、客户端）。
2. 什么是无人设备的故障告警闭环？
具体如下图：
- 机器端：设备通过工控将出发的软件or硬件故障同步到监控平台（服务端）；
- 服务端：监控平台经过一系列的告警策略，将告警消息推送至运维人员（客户端）；
- 客户端：运维人员接收告警通知后，到设备点位处维护设备；
- 机器端：设备维护完成，更新设备状态并上传到服务端。
02 用户画像和需求
1. 用户A
小张，男，25岁，一线运维工作人员
负责xx分公司xx线路的设备故障维护工作。由于下属负责的区域较广，区域内无人设备数量较多，随之而来的故障也较多。小张对于故障的接收仍依赖于设备场地方工作人员的投诉、客服人员的短信以及补货人员的信息同步。
希望有一个故障告警的推送服务，实时告知他哪台设备有故障需要维护，哪条告警优先级更高更紧急，该推送服务将会极大提升他的日常工作效率。
2. 用户B
老李，男，30岁，总部项目运营负责人
负责公司总部xx无人设备产品的线下运营。由于工作压力大，责任大，每天都需要对全国设备的运行情况有一个整体的掌握，但目前对设备运营状态的了解手段还停留在初级阶段，需要每日让下属收集数据，过程较为繁琐，同时效率较低，时间成本较高。
希望有一个实时的故障监控平台，能让他任何时候都能了解到全国无人设备的运营情况、故障情况以及告警处理情况。
03 功能结构组成
在调研了行业内产品和用户需求后，笔者将运维故障告警平台的组成拆分为如下几个部分：
故障数据+故障监控+故障告警+告警处理+设备健康度评分
1. 故障数据
关于故障数据，笔者建议可从如下几步着手：
故障数据分类 + 故障数据存储 + 故障数据筛选和过滤 + 故障数据仓库产品化
故障分类：行业内对于无人设备故障的分类大多较为成熟，具体举例如下：
对于不同类型的故障，将制定针对性的告警策略用于告警的触发和推送。
故障数据存储：根据无人设备的软硬件底层设计，提前制定一套相对匹配公司业务需求的存储字段，如设备号、故障名称、故障码、故障开始时间、恢复时间、持续时间、故障次数等；至于数据存储的逻辑，由于不同的产品业务差异较大，笔者就不过多赘述了；
故障数据筛选和过滤：即人为过滤掉不影响无人设备正常交易的故障或是运营运维人员在补理货和维护故障时产生的干扰性故障；
好处是：
- 减少干扰性故障，聚焦关键故障；
- 降低运维人员的关注成本，提高工作效率；
数据仓库产品化：通过一定的形式将每一条故障保存至产品化仓库中，便于后期及时更新和维护；围绕数据仓库，开展产品设计：
故障的展示方式如上：通过故障码+故障名称+故障类型+告警指标+紧急度+解放方案的形式进行维护，产品功能设计上支持：
- 故障新增；
- 故障查询；
- 故障编辑；
- 告警指标的新增；
当然，故障码的新增依赖于设备最初在软硬件层面的底层设计，有兴趣的同学可以进行更深层次的研究和学习，笔者就不作详细介绍了；
对于“单个故障”和“告警指标”的对应关系，将在接下来的故障告警中详细介绍。
2. 故障监控
结合实际业务和需求，笔者将之分为故障日志监控、故障告警监控；
故障日志监控：以单条故障作为最小颗粒度，对单台设备进行实时监控和记录；
故障告警监控：以一条告警任务作为做小颗粒度，对单台设备的实时状态和维护进度进行记录，并在运维人员维护完毕后同步告警任务及设备状态。
围绕故障监控的相关概念，开展设计如下：
故障日志监控
以单台设备—单条故障码的形式进行列表实时展示，功能上实现一定字段的查询、筛选和导出。
故障告警监控
通过“单台设备—单个告警”的形式进行列表展示，单个告警可包含多条故障，最终以告警任务的状态作为闭环监控的最后关键节点。功能设计上实现一定字段的查询、筛选和导出，同时对单台无人设备的告警任务，提供任务内详情查看（如告警任务领取时间、告警任务领取人员等信息）。
3. 故障告警
行业内对于“故障告警”在产品层面有多种实现方式，笔者在研究了多个产品并调研了业务需求后，将故障告警理解为故障告警策略，并将之拆分为如下几个组成部分：
故障告警策略 = 告警名称 + 告警对象 + 告警指标 + 触发条件 + 消息推送；
告警名称：即整条告警指标的名称，比如告警指标-“温度异常”，可命名为xx设备温度过高告警；
告警对象：即该告警对哪些设备有效，在无人零售行业，该类设备大多为饮料机、弹簧机、挂钩机、综合机、无人货架、无人货柜等；
告警指标：即对某一个或某一类故障统一指定的告警名称，该处设计在产品层面体现在将多个同类的故障归类为单一的告警指标；比方说，温度过低&温度过高，实际为两条故障码，但可以人为将之合并为一条告警指标—“温度异常”；该设计的优势在于，一线的运维工作者不用针对一类故障去逐一对接和记忆故障码和故障名称，取而代之的是仅记忆一条告警指标即可；
触发条件：指触发告警任务生成的的条件，笔者根据实际业务将触发条件大致分为如下三类：
消息推送：指通过一定的渠道，将消息推送到相关权限人员的手机客户端中；
围绕上述几个组成部分，开展产品设计，原则为：配置规则简单灵活，自定义指标值，自定义触发条件，自定义消息推送渠道。
进入告警配置列表：实现多字段查询和筛选、新增告警、编辑告警、关闭和启用告警。
新增告警配置：输入告警名称，选择对应的告警对象，告警指标可自由选择，触发条件为笔者结合实际业务需求后制定的初步方案，基本覆盖所有的告警指标并支持自定义值；
消息推送默认为内部app友智慧，运维人员可通过手机客户端实时接收告警推送消息。此处笔者不建议各位同学们使用平台消息推送，因为B端平台网页的自动刷新会给服务器带来一定的负荷，但手动刷新对人的要求较高，所以不推荐；邮件推送的方式可根据实际情况选用。
4. 告警处理
即一线运维人员通过手机客户端接收告警消息并领取，直到在设备点位处维护完成的过程，该过程为故障告警闭环的重要一环；
告警处理分为：告警消息接收 + 告警任务领取 + 机器端故障维护和清除。
告警处理的设计原则为：消息展示清晰、消息内容简单易懂、告警任务领取方便、机器端告警清除方便。之所以将告警清除放在机器端是为了在一定程度上防止人员操作的漏洞…（此处省略100个字）；
围绕上述原则，开展产品设计：
首先为运维人员手机端
提供告警任务清单和优先级排序（优先级排序根据业务不同，策略逻辑差异较大，此处笔者就跳过了），同时告警详情中对单台无人设备下的多个告警任务可进行自由接取，并支持批量接取，接取任务后同步接取信息至服务器。
此处笔者将告警任务设计为了抢单式，而非传统的派单式，对于抢单式vs派单式的优缺点，有兴趣的同学可作深度研究，此处笔者就省略1000字了～
最后为机器端
运维人员在设备维护完成后，通过无人设备的屏幕进入维护界面，清除相应的告警，此时告警完成，完成情况同步至后台服务器，整个运维故障告警闭环即宣告完成。
总结
在整个告警闭环的设计中，通过明确告警即制定告警策略，针对告警策略进行拆解，同时结合真实的业务场景需求制定了匹配业务的告警触发条件，最终形成有效的告警推送并由客户端接收和落地执行。
此外，平台仍能针对几个方面进行持续性的优化：
- 更简单快捷的告警配置方式；
- 更加细分的告警对象来提升告警的精准度；
- 更加符合业务目标的告警触发条件。
本文作者 @Mr.张锦鲤 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
