筆者在近期的日常工作中，發現公司內對於無人設備的故障告警和維護長久以來沒有形成一個完整的業務閉環，導致一線的運維工作人員效率較低，對用戶的體驗也造成了一定的負面影響。因此，筆者針對性的研究了行業內的相關產品，同時對相關業務人員的需求進行了調研，最終初步形成了運維故障告警平臺。
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.張錦鯉 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。