智能货柜专题二：怎么提升机器故障处理效率？

harryli 2023-07-22 07:02:43

01 背景

由于智能货柜涉及到硬件系统，不像电商直接是在线上（APP、小程序等载体）完成下单购买，因此可能会遇到网络故障、摄像头故障、门锁等硬件故障，而有些故障一旦出现就会导致机器无法正常售卖，无法正常售卖则将直接造成亏损，因此对于我们来说，怎么提升故障的处理效率是自动售卖机行业的一个重要工作，一般和硬件相结合的产品都可能会遇到这类故障问题。

但是智能货柜不一样，因为是无人零售，现场是一般不会有工作人员维护的，而一些超市的刷脸支付、地铁的闸机等因为一般都会有工作人员在现场，发现故障和处理故障都会容易很多。

02 故障的定义与分类

首先是怎么去清晰的货柜有哪些故障，怎么尽可能多的去枚举出可能潜在的故障，而对于智能货柜来说涉及到如下的故障：

硬件类故障：门锁故障、刷脸摄像头故障、视觉识别摄像头故障、压缩机故障、串口故障、网络故障等等；
软件类故障：交易超时、开门时间过长、内存不足、死机等等。

而其中很多硬件类的故障因为涉及到软件和硬件的接口通讯协议，因此针对这些故障很多都没有自检的机制，我们的做法是通过定义错误码来与故障进行关联，也就是通过故障编辑的后台，定义出所有的故障码，每个故障码分别对应一个类型的故障，每一个故障都需要有以下的字段去定义：

故障码
故障名称
故障类型
故障等级
推荐解决的方案

这里就不重点展开相关的介绍，可以参考我的另外一篇文章：《如何从0到1搭建故障监控与告警系统》

03 怎么提升故障告警的及时性和有效性

怎么提升故障告警的及时性和有效性，这个问题其实可以拆解成2个问题，第一个问题怎么判断一个故障需不需要将告警通知下发给相应的人员处理，第二个问题就是怎么保证故障通知能真正的触达到运维人员，避免运维人员忽略掉通知从而影响故障的处理效率。

1. 故障告警的策略

正如我们上文提到的，清晰的定义了每个故障之后，就需要对这些故障配置相应的告警策略，这里还是需要有一个故障监控的策略配置后台，不仅仅是针对某一个故障码的策略，有时候还需要对多个故障码配置关联的告警策略。比方说监控摄像头故障，需要配置该故障的告警策略如下：

故障名称：摄像头故障
监控指标：故障发生次数
统计时间：24小时
告警触发条件：3次

也就是针对摄像头故障，如果在24小时内连续出现3次就会触发告警通知的策略，而一些多维度的告警策略就相对比较复杂了，比方说温度监控和压缩机故障：故障触发的条件就可能是温度超过20度持续时间超过30分钟，同时压缩机故障代码发生N次，这里其实就是避免故障上报不准确造成误报，比方说有可能是因为开门时间过长，导致冰箱内部温度过高，这时候如果直接告警的话有可能会造成运维人员白白去了一趟现场维修。

2. 故障告警的通知

在配置故障策略的时候，每个故障都可以支持配置故障通知的渠道和故障接收人，有一些故障是需要去现场处理的，这个通知一般都直接推送给机器的运维人员，而一些软件类的故障则可能需要直接推送到相应的开发人员，从而做到故障的分工处理，进而提高故障处理的效率，另外故障通知的渠道也需要进行配置，一般涉及到如下通知渠道：

钉钉：告警机器人，通过群告警机器人自动推送通知
微信服务号（小程序）：通过模板消息实时下发
短信通知：一般对接第三方的短信渠道，会有一定的费用
邮件通知：一般用来通知开发人员，通过企业邮箱推送
APP、运营后台：通过运营端的APPpush通知，或者运营后台的消息推送

这里面实践证明，微信服务号小程序的模板消息通知的效率最高，但是有一个问题就是模板消息有上限，超过之后没办法继续发送；另外就是钉钉的推送效果也还行，至少能保证都能推送到相应的人，APPpush如果运维人员没有打开消息通知则可能无法推送，这里的一个策略就是每次进去运营APP时都要去检测运维人员是否打开消息通知，没有打开则引导打开。

04 怎么提升故障处理的效率和时效

前面提到了故障定义与分类，故障的上报，故障的策略配置，故障的通知，这些都是为了提升故障处理的效率做的铺垫，最终核心需要解决的就是怎么提升故障处理的时效，完成整个故障的闭环。

我们之前只是做到了故障的通知下发，并没有去监控故障处理的效果，导致一台机器发生故障有时候可能需要3天才能去现场处理，因此我们主要将问题拆解如下，并逐一去解决这些问题：

1. 当运维人员频繁收到故障告警的通知时，怎么保证他不会忽略掉某些故障通知？

首先需要解决的就是怎么不频繁地进行告警，这就需要我们监控告警策略是不是配置得当，另外就是针对同一台机器同一个故障，比方说12个小时内只推送一次，从而降低整个故障通知的量级；

第二就是怎么去保证他不会忽略掉这些故障告警，我们通过系统的待办功能去解决，也即每一个故障都对应了一个智能待办，没有处理完毕的故障待办就会一直在系统中。

产品经理，产品经理网站

2. 当一个运维人员同一时间收到多个故障通知的时候，怎么判断应该先去维修哪台机器？

这里我们就要回到最初的故障定义上面来，每一个故障或者配置的策略都会有一个故障等级，其次故障等级还和次数以及持续时间有关系，另外比方说有一台机器A每天的销量是500元，另外一台机器B每天的销量是50元，这时候2台机器都有故障需要处理，那很显然应该首先去维修机器A，所以还是需要依赖我们的策略未帮助运维人员智能的判断哪台机器更应该去补货，而可能不是一个先来后到的处理方式，是一个动态排序的过程。

3. 怎么提升运维人员处理故障的积极性？

这里面其实不仅仅是涉及到产品方案的问题了，其实还涉及到公司管理与政策的问题。

首先产品方案上，我们为分公司的管理人员以及机器的业务人员开发了一个故障监控和处理的看板，每天都能直观的看到故障的发生率与处理率，我们在全公司做了故障发生率和处理率的排序，管理人员可以很明晰的看出来，通过自上而下的推动，去引导分公司重视起来故障的处理。

同时我们不仅只展示单单的故障信息，我们直接将故障带来的损失进行量化，比方说某某分公司故障机器10台，因为故障带来的销售损失预估为1000元，通过带来的损失去刺激分公司处理故障的积极性。

另外业务员机器的销量直接和他们挂钩，如果故障影响了销量，业务员我们每天的日报以及未恢复的机器发送给他们，他们也能推动相应的运维人员去处理

第二是在管理和政策上面，分公司层面和运维人员都执行考核政策，可以想象如果运维人员拿的是死工资，固定的工作时间，那他们的积极性必然会受到影响，每天可能就是按时收工。但是如果我们制定相应的奖惩措施，通过故障处理率和时效去考核，那么他们必然会去努力提升故障处理的积极性，毕竟是和他们的待遇直接挂钩。

第三运维人员可以自己看到自己的成果，也就是日报周报月报的形式，通过成果的直观展示去给运维人员带来成就感

所以有时候我们可以多思考，有些问题不一定都需要通过产品方案去解决，有时候可能通过流程和相应的制度会达到更好的效果。

4. 针对某些故障，运维人员不知道怎么去处理怎么办？

也就是当我们故障下发和生成待办之后，对于一些新的故障和新的运维人员，他要怎么去更快的定位问题和处理，这里面涉及到2个方面的解决方案

第一产品层面：就是我们针对每个故障都会在后台维护相应的解决方案，在下发故障通知的时候就会直接告知运维人员；另外就是在运营工具中，会定期更新故障知识库，里面会针对所有的故障展示详细的解决方案；

第二运营层面：定期组织故障的培训，针对新的员工进行指导；另外就是会组织一些运维比赛，通过奖励提升运维人员的技能。

5. 是不是所有的故障都需要现场处理，怎么解决故障的误报，以及怎么监控故障是否真的恢复？

第一，我们发现并不是所有的故障都需要去现场处理，我们针对某些故障设置了重启的策略，万能的重启可以解决很多小故障的问题，同时也为运维人员提供了远程重启的功能，有时候可以通过远程手动重启去恢复；

第二是怎么解决故障的误报，针对一些故障我们会有自检和定时检测的机制，如果误报，再下一次自检的时候发现已经没有故障了，另外加了一个留观时长，在这个时长内故障没有复发，则我们会自动清除待办并推送故障恢复的通知；

第三个问题是怎么避免运维人员偷懒作弊，检查故障是否真的恢复，我们做了2个方案去规避，第一个就是我们只支持在机器端现场进行故障待办的处理，处理完成后在机器端点击完成，除了误报的故障通过自检可以处理，其他的故障基本上都需要去现场维修。

总结

通过故障的定义与分类，故障的上报、故障的策略配置，故障的告警通知以及故障的处理闭环，我们的故障发生率以及处理的时效都得到了极大的改善。

首先我们通过监控到一些硬件和软件类的故障，推动硬件去进行改造降低故障率；同时软件类的相应故障我们也进行了优化，使故障发生率降低了30%；另外通过各种措施提升了故障的时效，故障的处理时效从原来的3天提升到了1天以内，效果是非常的显著，直接减少公司的销售损失数百万元。

另外这里也给了我们一个启示：

首先是需要站在多方去思考整个交易模型：

比方说对于我们来说做这个项目有什么价值；对于用户来说，极大的提高了用户体验，避免用户来了货柜前面因为故障而买不了东西，提升了用户的效用；站在运维人员角度来说，降低了他们的操作难度，提升了他们处理故障的效率；而对于平台来说，则是实打实的降低了销售损失间接提升了收益。

另外一个方面的启示就是，需要从多维度去拆解问题，并不是所有的问题都只能通过产品方案去解决，有时候制度、政策或者完善的流程都能达到意想不到的效果，这也需要产品经理对业务能更加的熟悉。