一、有關故障監控與告警的基礎知識

智能貨柜同一般的軟件有較大的區別，軟件只涉及服務應用層面的交互，而智能貨柜則既涉及到軟件應用的交互，還涉及到硬件和軟件的交互，因此智能貨柜的故障和監控要比普通的APP以及系統要更加復雜，下面就故障監控與告警相關的背景和知識做相應的介紹。

1. 什么是故障？

百度百科對于故障的解釋如下：

故障是系統不能執行規定功能的狀態。通常而言，故障是指系統中部分元器件功能失效而導致整個系統功能惡化的事件。

而對于智能貨柜來說，故障即是任何會影響設備正常售賣的事件，包括硬件上的故障，也包括軟件上的故障。

• 硬件上的故障包括：鎖故障、門故障、制冷故障、貨道故障等；
• 而軟件上的故障則包括：無法支付、軟件死機、卡屏、交易失敗等。

故障的種類有可能是非常多的，對于產品而言只能在最開始系統設計的時候，盡可能的窮舉出越多的故障，只有明確了故障的種類，才能監控到這些故障。

那我們為什么要做故障監控與告警系統呢？

對于智能貨柜來說，每一個運營都需要負責非常多的設備，而不能時時刻刻守在設備旁邊，也就無法及時知道設備發生了故障，因此故障監控與告警系統將會產生如下價值：

• 及時性：自動獲知機器故障信息，并將故障信息傳遞給對應的線下運營人員，第一時間解決機器故障，恢復設備售賣；
• 收益性：設備故障無法售賣，自然會降低設備的交易額，而通過故障監控告警，可以最大程度的降低運營的損失，提高機器交易額，也就為公司創造了更大的效益；
• 同時故障監控和告警也會積累大量的數據信息，為產品的迭代和優化提供強有力的支持，提升產品的性能和體驗。

監控與告警的區別：其實本質上監控是告警的基礎，只有具備了監控的信息，才能針對監控的信息去指定相應的規則和策略來進行告警。監控的信息是非常全和雜的，但是對于接受故障的用戶來說，雜和全的信息會干擾用戶的判斷和決策，因此只有在監控信息基礎上，針對相應的規則篩選出需要告警的信息來進行觸達和展示，才能最大效率和準確的解決相應的故障。

監控和告警的目標則是一致的，即：

• 全面：監控與告警的廣度，盡可能多的覆蓋到故障類型
• 及時：數據處理和傳遞的時效性，快速的將告警信息暴露出來
• 準確：保證監控和告警信息的準確性，避免浪費相應的資源去解決錯誤的告警。

既然是從0到1的系統，那自然不免會涉及到非常多的工作需要去找。前期用戶調研、競品調研以及市場背景都要去了解。

用戶調研：因為系統做出來不是給產品用的，因此必須要了解該系統使用對象的想法。一般來說針對公司自己軟硬件的故障監控系統，都是給公司內部相關部門的人使用的，因此用戶調研上相對來說會比較容易，需要了解使用對象的使用習慣、對于哪些故障類型比較關注，盡可能多的收集故障類型。

競品調研：一般來說對于陌生的產品和系統，為了避免更少的踩坑，還是需要多多體驗市場上存在的產品，包括成熟和不成熟的系統都可以去參考，能夠產生許多的靈感。

以上2點是做該系統比較簡單的工作，以下內容則涉及到故障監控與告警系統具體的產品設計方案。

1. 故障監控與告警系統的基礎

首先要做故障的監控，就必須要了解和清楚怎么去監控設備硬件和軟件的相關信息，主要通過如下方式去監控故障：

• 硬件上報：首先在做一款智能貨柜的時候，如果是定制化的機器，在機器出廠之前，在硬件上就需要雙方協定做好哪些協議和串口，此時需要硬件和軟件產品經理共同探討，在出廠前就需要明確需要監控哪些硬件故障，而為了監控這些故障，必然需要在硬件上做相應的開發。比方說要監控機器的溫度，如果機器沒有上報溫度的串口和協議，那我們必然無法監控到溫度異常的故障；
• 軟件埋點：軟件埋點更多的涉及到前端交互頁面的監控，比方說某個按鈕的點擊率，某些環節的轉化率，而只有這些地方埋點后，我們才能監控到這些數據，才能判斷是否軟件出現異常和故障；
• 服務器與日志上報：服務器和日志更多的是通過后臺接口的方式進行監控，比方說某個接口宕機或者高并發掛掉，而后臺的故障事先都需要定義好相應的錯誤碼，通過故障錯誤碼來監控故障信息。

只有以上工作做到位后，才能具備監控和告警的基礎，不然沒有這些信息，后面也沒辦法實現故障的監控和告警。

2. 故障監控的類型

前期在故障類型較少的時候，有可能是通過開發代碼定義故障類型，但是為了后續系統的拓展和兼容性，建議還是通過頁面配置的方式來實現故障類型定義。

以下通過智能硬件的故障類型來給大家詳細說明，故障類型的編輯可能涉及到如下字段來區分故障：

• 故障id：故障id是唯一的，每個故障都會上報一個故障id，通過故障id可以唯一確定每個故障；
• 故障類型：故障類型其實也是可以通過前端頁面自定義創建的，在此可以直接通過下拉選擇故障類型，如果要新增故障類型則通過新的頁面去操作；
• 故障名稱：通過故障id無法直觀知道每個故障，通過名稱則很直觀和清晰的知道每個故障信息；
• 故障等級：故障等級對于故障告警的策略和編輯是非常有用的，此字段也是必要的；
• 推薦解決方案：推薦解決方案是給相應的運維人員查看的，對于一些新運維人員需要通過此信息去指導運維人員去解決相應的故障。

以上字段是對一個故障最基礎的編輯和定義，當上報一個故障id時，則可以通過故障id去拉取該故障的其他信息。不同的業務可能對于故障的定義字段都不盡相同，需要根據業務去靈活制定。

3. 故障告警的規則和策略

正如上文提到的，故障監控和告警是兩個不同的事情，監控是把所有上報的信息都會記錄下來，所以信息一定是多而雜的，這些過多的信息如果都推送給相應的人員，那很可能是大大提高了用戶處理錯誤信息的工作量，所以是需要規則和策略去篩選準確的故障信息進行推送。

那么告警規則和策略包含哪些信息呢？簡單粗暴的來說，一個告警規則和策略需要包含告警的統計指標，告警推送的條件、告警的收斂規則。

舉例如下：

比方說針對網絡故障的告警，則對應的監控項為網絡速度，那么創建一個告警規則需要定義如下信息：

• 告警名稱：網絡故障告警
• 告警指標：網絡速度
• 告警條件：網絡速度小于20kb/s
• 統計時間：30分鐘
• 發生次數：3次

那么當某臺設備30分鐘內上報網速小于20kb/s大于等于3次時，就需要通過告警推送到對應的人員。告警規則也是可以通過前端頁面去靈活配置的，這也大大提高了系統的拓展性和廣泛使用性，可以及時跟進數據情況修改和新增相應的告警規則。

4. 故障告警的方式和渠道

當系統監控到需要推送告警信息時，需要通過什么渠道推送告警信息呢？這里也涉及到前期用戶調研的一些內容，一定是需要通過最簡單、高效的渠道去推送到運維人員手中，主要有以下方式和渠道來進行推送告警信息：

• 告警后臺系統：通過數據倉庫可視化的告警以及告警列表來推送相應的信息。此種方式是最基礎的信息來源，但是運維人員不可能時刻打開后臺系統來查看，因此此種方式是比較不適用的不高效的；
• 郵件：一般使用系統的人員有可能是使用電腦的，但是對于智能貨柜的用戶群體來說，他們經常都不在辦公室奔波于線下，如果手機未安裝郵箱APP，則無法及時獲知告警信息；
• 微信公眾號：通過微信公眾號的模板消息來進行觸達是非常高效的，使用的人員能夠及時收到相應的告警信息，而且微信公眾號的模板消息是免費的；
• APP推送：APP相較于后臺系統還是有效許多的，通過APP消息推送和內部的告警模塊進行觸達，主要是由于運維人員用的最多的就是APP，需要用到APP補貨、查詢數據等，所以通過此方式也是非常可行的。

以上列了主要的幾種告警推送的方式和渠道，其實還包括一些其他的方式，比方說釘釘群、微信群、短信等，至于需要通過哪種方式去推送告警信息，一般都是需要根據業務來確定，也不一定是只通過一種方式去觸達。為了保證告警的效果，可以多種方式同時推送，但是前期也需要平衡開發的成本和收益，選擇一種最高效、開發難度最小的進行觸達。

三、故障監控和告警系統總結

故障監控和告警系統其實相對來說還是一個比較簡單的系統，但是如果需要從0到1的去搭建這樣一個系統也是需要注意比較多的情況，盡可能系統化、模塊化的去設計這樣一個系統。

• 做好充分的用戶調研、競品調研和背景分析，充分挖掘用戶的痛點和需求，參考成熟的一些系統方案；
• 前期基礎需要搭好，一定要搭建好故障上報的體系，沒有渠道去獲取相關的故障信息則無法做故障的告警，則后續系統的搭建也是白搭；
• 故障的定義、告警的規則和策略是該系統的核心，需要盡可能多的整理總結故障類型，覆蓋多一些故障，其次也需要根據實際情況不斷去調整故障告警的規則和策略，優化迭代故障告警的準確率。
• 通過何種渠道去推送告警信息，也是需要根據用戶的使用習慣，結合開發實現的難度和成本去綜合考量，必要的話可以采取多種方式去推送，以提高故障觸達率與解決時效。

來源：機房動力環境監控 http://m.28ut.com   本文采集于網絡，如有問題有聯系刪除