科技对零售业的颠覆已经到了科幻级别。不用集齐七龙珠那么麻烦，一部下载了对应App的手机就能让你把便利店“召唤”到自己身边。
无人零售货柜受欢迎原因： 中国的零售业成本太高了，仓储成本、采购成本各个环节成本都非常的高； 无人货柜真正的意义在于它所搜集到的数据； 目前便利零售行业是一个增长缓慢的市场，在一个增长不快的市场中，抢占的其实是原有的市场份额。
无人零售系统结构
- 机器端：设备通过工控将出发的软件or硬件故障同步到监控平台（服务端）；
- 服务端：监控平台经过一系列的告警策略，将告警消息推送至运维人员（客户端）；
- 客户端：运维人员接收告警通知后，到设备点位处维护设备；
- 机器端：设备维护完成，更新设备状态并上传到服务端。
调研了行业内产品和用户需求后，将运维故障告警平台的组成拆分为如下几个部分：
故障数据+故障监控+故障告警+告警处理+设备健康度评分
1. 故障数据
故障数据分类 + 故障数据存储 + 故障数据筛选和过滤 + 故障数据仓库产品化
对于不同类型的故障，将制定针对性的告警策略用于告警的触发和推送。
故障数据存储：根据无人设备的软硬件底层设计，提前制定一套相对匹配公司业务需求的存储字段，如设备号、故障名称、故障码、故障开始时间、恢复时间、持续时间、故障次数等；至于数据存储的逻辑，由于不同的产品业务差异较大，笔者就不过多赘述了；
故障数据筛选和过滤：即人为过滤掉不影响无人设备正常交易的故障或是运营运维人员在补理货和维护故障时产生的干扰性故障；
好处是：
- 减少干扰性故障，聚焦关键故障；
- 降低运维人员的关注成本，提高工作效率；
数据仓库产品化：通过一定的形式将每一条故障保存至产品化仓库中，便于后期及时更新和维护；围绕数据仓库，开展产品设计：
故障的展示方式如上：通过故障码+故障名称+故障类型+告警指标+紧急度+解放方案的形式进行维护，产品功能设计上支持：
- 故障新增；
- 故障查询；
- 故障编辑；
- 告警指标的新增；
当然，故障码的新增依赖于设备最初在软硬件层面的底层设计，有兴趣的同学可以进行更深层次的研究和学习，笔者就不作详细介绍了；
对于“单个故障”和“告警指标”的对应关系，将在接下来的故障告警中详细介绍。
2. 故障监控
结合实际业务和需求，笔者将之分为故障日志监控、故障告警监控；
故障日志监控：以单条故障作为最小颗粒度，对单台设备进行实时监控和记录；
故障告警监控：以一条告警任务作为做小颗粒度，对单台设备的实时状态和维护进度进行记录，并在运维人员维护完毕后同步告警任务及设备状态。
故障告警监控
通过“单台设备—单个告警”的形式进行列表展示，单个告警可包含多条故障，最终以告警任务的状态作为闭环监控的最后关键节点。功能设计上实现一定字段的查询、筛选和导出，同时对单台无人设备的告警任务，提供任务内详情查看（如告警任务领取时间、告警任务领取人员等信息）。
3、告警处理
即一线运维人员通过手机客户端接收告警消息并领取，直到在设备点位处维护完成的过程，该过程为故障告警闭环的重要一环；
告警处理分为：告警消息接收 + 告警任务领取 + 机器端故障维护和清除。
告警处理的设计原则为：消息展示清晰、消息内容简单易懂、告警任务领取方便、机器端告警清除方便。之所以将告警清除放在机器端是为了在一定程度上防止人员操作的漏洞…（此处省略100个字）；
围绕上述原则，开展产品设计：
首先为运维人员手机端
提供告警任务清单和优先级排序（优先级排序根据业务不同，策略逻辑差异较大，此处笔者就跳过了），同时告警详情中对单台无人设备下的多个告警任务可进行自由接取，并支持批量接取，接取任务后同步接取信息至服务器。
运维人员在设备维护完成后，通过无人设备的屏幕进入维护界面，清除相应的告警，此时告警完成，完成情况同步至后台服务器，整个运维故障告警闭环即宣告完成。