無人零售產(chǎn)品:如何從0-1搭建運維故障告警平臺?

11 評論 12675 瀏覽 149 收藏 14 分鐘

筆者在近期的日常工作中,發(fā)現(xiàn)公司內(nèi)對于無人設備的故障告警和維護長久以來沒有形成一個完整的業(yè)務閉環(huán),導致一線的運維工作人員效率較低,對用戶的體驗也造成了一定的負面影響。因此,筆者針對性的研究了行業(yè)內(nèi)的相關產(chǎn)品,同時對相關業(yè)務人員的需求進行了調(diào)研,最終初步形成了運維故障告警平臺。

01 引入概念

1. 什么是告警?

顧名思義,即系統(tǒng)發(fā)生故障時,監(jiān)控單元根據(jù)指定的告警策略,通過提前確定好的推送渠道,將告警通知推送給指定的接收方(服務端、客戶端)。

2. 什么是無人設備的故障告警閉環(huán)?

具體如下圖:

  • 機器端:設備通過工控將出發(fā)的軟件or硬件故障同步到監(jiān)控平臺(服務端);
  • 服務端:監(jiān)控平臺經(jīng)過一系列的告警策略,將告警消息推送至運維人員(客戶端);
  • 客戶端:運維人員接收告警通知后,到設備點位處維護設備;
  • 機器端:設備維護完成,更新設備狀態(tài)并上傳到服務端。

02 用戶畫像和需求

1. 用戶A

小張,男,25歲,一線運維工作人員

負責xx分公司xx線路的設備故障維護工作。由于下屬負責的區(qū)域較廣,區(qū)域內(nèi)無人設備數(shù)量較多,隨之而來的故障也較多。小張對于故障的接收仍依賴于設備場地方工作人員的投訴、客服人員的短信以及補貨人員的信息同步。

希望有一個故障告警的推送服務,實時告知他哪臺設備有故障需要維護,哪條告警優(yōu)先級更高更緊急,該推送服務將會極大提升他的日常工作效率。

2. 用戶B

老李,男,30歲,總部項目運營負責人

負責公司總部xx無人設備產(chǎn)品的線下運營。由于工作壓力大,責任大,每天都需要對全國設備的運行情況有一個整體的掌握,但目前對設備運營狀態(tài)的了解手段還停留在初級階段,需要每日讓下屬收集數(shù)據(jù),過程較為繁瑣,同時效率較低,時間成本較高。

希望有一個實時的故障監(jiān)控平臺,能讓他任何時候都能了解到全國無人設備的運營情況、故障情況以及告警處理情況。

03 功能結構組成

在調(diào)研了行業(yè)內(nèi)產(chǎn)品和用戶需求后,筆者將運維故障告警平臺的組成拆分為如下幾個部分:

故障數(shù)據(jù)+故障監(jiān)控+故障告警+告警處理+設備健康度評分

1. 故障數(shù)據(jù)

關于故障數(shù)據(jù),筆者建議可從如下幾步著手:

故障數(shù)據(jù)分類 + 故障數(shù)據(jù)存儲 + 故障數(shù)據(jù)篩選和過濾 + 故障數(shù)據(jù)倉庫產(chǎn)品化

故障分類:行業(yè)內(nèi)對于無人設備故障的分類大多較為成熟,具體舉例如下:

對于不同類型的故障,將制定針對性的告警策略用于告警的觸發(fā)和推送。

故障數(shù)據(jù)存儲:根據(jù)無人設備的軟硬件底層設計,提前制定一套相對匹配公司業(yè)務需求的存儲字段,如設備號、故障名稱、故障碼、故障開始時間、恢復時間、持續(xù)時間、故障次數(shù)等;至于數(shù)據(jù)存儲的邏輯,由于不同的產(chǎn)品業(yè)務差異較大,筆者就不過多贅述了;

故障數(shù)據(jù)篩選和過濾:即人為過濾掉不影響無人設備正常交易的故障或是運營運維人員在補理貨和維護故障時產(chǎn)生的干擾性故障;

好處是:

  1. 減少干擾性故障,聚焦關鍵故障;
  2. 降低運維人員的關注成本,提高工作效率;

數(shù)據(jù)倉庫產(chǎn)品化:通過一定的形式將每一條故障保存至產(chǎn)品化倉庫中,便于后期及時更新和維護;圍繞數(shù)據(jù)倉庫,開展產(chǎn)品設計:

故障的展示方式如上:通過故障碼+故障名稱+故障類型+告警指標+緊急度+解放方案的形式進行維護,產(chǎn)品功能設計上支持:

  1. 故障新增;
  2. 故障查詢;
  3. 故障編輯;
  4. 告警指標的新增;

當然,故障碼的新增依賴于設備最初在軟硬件層面的底層設計,有興趣的同學可以進行更深層次的研究和學習,筆者就不作詳細介紹了;

對于“單個故障”和“告警指標”的對應關系,將在接下來的故障告警中詳細介紹。

2.?故障監(jiān)控

結合實際業(yè)務和需求,筆者將之分為故障日志監(jiān)控、故障告警監(jiān)控;

故障日志監(jiān)控:以單條故障作為最小顆粒度,對單臺設備進行實時監(jiān)控和記錄;

故障告警監(jiān)控:以一條告警任務作為做小顆粒度,對單臺設備的實時狀態(tài)和維護進度進行記錄,并在運維人員維護完畢后同步告警任務及設備狀態(tài)。

圍繞故障監(jiān)控的相關概念,開展設計如下:

故障日志監(jiān)控

以單臺設備—單條故障碼的形式進行列表實時展示,功能上實現(xiàn)一定字段的查詢、篩選和導出。

故障告警監(jiān)控

通過“單臺設備—單個告警”的形式進行列表展示,單個告警可包含多條故障,最終以告警任務的狀態(tài)作為閉環(huán)監(jiān)控的最后關鍵節(jié)點。功能設計上實現(xiàn)一定字段的查詢、篩選和導出,同時對單臺無人設備的告警任務,提供任務內(nèi)詳情查看(如告警任務領取時間、告警任務領取人員等信息)。

3. 故障告警

行業(yè)內(nèi)對于“故障告警”在產(chǎn)品層面有多種實現(xiàn)方式,筆者在研究了多個產(chǎn)品并調(diào)研了業(yè)務需求后,將故障告警理解為故障告警策略,并將之拆分為如下幾個組成部分:

故障告警策略 = 告警名稱 + 告警對象 + 告警指標 + 觸發(fā)條件 + 消息推送;

告警名稱:即整條告警指標的名稱,比如告警指標-“溫度異?!保擅麨閤x設備溫度過高告警;

告警對象:即該告警對哪些設備有效,在無人零售行業(yè),該類設備大多為飲料機、彈簧機、掛鉤機、綜合機、無人貨架、無人貨柜等;

告警指標:即對某一個或某一類故障統(tǒng)一指定的告警名稱,該處設計在產(chǎn)品層面體現(xiàn)在將多個同類的故障歸類為單一的告警指標;比方說,溫度過低&溫度過高,實際為兩條故障碼,但可以人為將之合并為一條告警指標—“溫度異?!?;該設計的優(yōu)勢在于,一線的運維工作者不用針對一類故障去逐一對接和記憶故障碼和故障名稱,取而代之的是僅記憶一條告警指標即可;

觸發(fā)條件:指觸發(fā)告警任務生成的的條件,筆者根據(jù)實際業(yè)務將觸發(fā)條件大致分為如下三類:

消息推送:指通過一定的渠道,將消息推送到相關權限人員的手機客戶端中;

圍繞上述幾個組成部分,開展產(chǎn)品設計,原則為:配置規(guī)則簡單靈活,自定義指標值,自定義觸發(fā)條件,自定義消息推送渠道。

進入告警配置列表:實現(xiàn)多字段查詢和篩選、新增告警、編輯告警、關閉和啟用告警。

新增告警配置:輸入告警名稱,選擇對應的告警對象,告警指標可自由選擇,觸發(fā)條件為筆者結合實際業(yè)務需求后制定的初步方案,基本覆蓋所有的告警指標并支持自定義值;

消息推送默認為內(nèi)部app友智慧,運維人員可通過手機客戶端實時接收告警推送消息。此處筆者不建議各位同學們使用平臺消息推送,因為B端平臺網(wǎng)頁的自動刷新會給服務器帶來一定的負荷,但手動刷新對人的要求較高,所以不推薦;郵件推送的方式可根據(jù)實際情況選用。

4. 告警處理

即一線運維人員通過手機客戶端接收告警消息并領取,直到在設備點位處維護完成的過程,該過程為故障告警閉環(huán)的重要一環(huán);

告警處理分為:告警消息接收 + 告警任務領取 + 機器端故障維護和清除。

告警處理的設計原則為:消息展示清晰、消息內(nèi)容簡單易懂、告警任務領取方便、機器端告警清除方便。之所以將告警清除放在機器端是為了在一定程度上防止人員操作的漏洞…(此處省略100個字);

圍繞上述原則,開展產(chǎn)品設計:

首先為運維人員手機端

提供告警任務清單和優(yōu)先級排序(優(yōu)先級排序根據(jù)業(yè)務不同,策略邏輯差異較大,此處筆者就跳過了),同時告警詳情中對單臺無人設備下的多個告警任務可進行自由接取,并支持批量接取,接取任務后同步接取信息至服務器。

此處筆者將告警任務設計為了搶單式,而非傳統(tǒng)的派單式,對于搶單式vs派單式的優(yōu)缺點,有興趣的同學可作深度研究,此處筆者就省略1000字了~

最后為機器端

運維人員在設備維護完成后,通過無人設備的屏幕進入維護界面,清除相應的告警,此時告警完成,完成情況同步至后臺服務器,整個運維故障告警閉環(huán)即宣告完成。

總結

在整個告警閉環(huán)的設計中,通過明確告警即制定告警策略,針對告警策略進行拆解,同時結合真實的業(yè)務場景需求制定了匹配業(yè)務的告警觸發(fā)條件,最終形成有效的告警推送并由客戶端接收和落地執(zhí)行。

此外,平臺仍能針對幾個方面進行持續(xù)性的優(yōu)化:

  1. 更簡單快捷的告警配置方式;
  2. 更加細分的告警對象來提升告警的精準度;
  3. 更加符合業(yè)務目標的告警觸發(fā)條件。

 

本文由 @Mr.張錦鯉 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協(xié)議。

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 故障數(shù)據(jù)篩選和過濾,是通過產(chǎn)品邏輯實現(xiàn)的嘛

    來自山東 回復
  2. 寫的很專業(yè)

    來自上海 回復
  3. 請問故障類型是啥

    來自江蘇 回復
  4. 讓我有了很系統(tǒng)的了解,感謝,寫得真好,完全理解了

    來自北京 回復
  5. 您好,圖中的系統(tǒng)可以看下嗎,我可以聯(lián)系您嗎,您的微信多少

    回復
    1. 可以參考下阿里云哈

      回復
    2. 您是參考那里的嗎

      回復
    3. 阿里云、華為云都是可以的

      回復
  6. 很棒的分享。不過運維人員搶單模式這個在企業(yè)內(nèi)部方便實現(xiàn)么?

    來自湖南 回復
    1. 這個可能需要從運維人員的業(yè)績構成的角度去入手,同時產(chǎn)品層面通過個人or分公司完成情況的數(shù)據(jù)看板進行激勵,兩步走吧,不過還需要更多的實踐,無人零售行業(yè)目前這塊兒相對還沒那么系統(tǒng)。

      回復
    2. 您好!我想問一下現(xiàn)在這種無人設備的運維工單,工單處理人員什么邏輯
      去處理,如果需要多個處理人員處理,工單怎么體現(xiàn)每個人的工作量

      來自山東 回復