智能貨柜專題二:怎么提升機器故障處理效率?
上一篇文章《智能貨柜專題一:如何讓“智能貨柜”的補貨效益最大化?》中,我們分析了怎么讓智能貨柜的補貨效益最大化,這篇文章將著重介紹當機器發生故障時,怎么提升故障處理的時效,進而保障機器能夠正常售賣,提升智能貨柜的銷售。
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天以內,效果是非常的顯著,直接減少公司的銷售損失數百萬元。
另外這里也給了我們一個啟示:
首先是需要站在多方去思考整個交易模型:
比方說對于我們來說做這個項目有什么價值;對于用戶來說,極大的提高了用戶體驗,避免用戶來了貨柜前面因為故障而買不了東西,提升了用戶的效用;站在運維人員角度來說,降低了他們的操作難度,提升了他們處理故障的效率;而對于平臺來說,則是實打實的降低了銷售損失間接提升了收益。
另外一個方面的啟示就是,需要從多維度去拆解問題,并不是所有的問題都只能通過產品方案去解決,有時候制度、政策或者完善的流程都能達到意想不到的效果,這也需要產品經理對業務能更加的熟悉。
相關閱讀
作者:harryli,新零售行業產品經理;公眾號:Harry李先生筆記
本文由 @harryli 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協議。
- 目前還沒評論,等你發揮!