一、有關故障監(jiān)控與告警的基礎知識

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

1. 什么是故障？

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

故障是系統(tǒng)不能執(zhí)行規(guī)定功能的狀態(tài)。通常而言，故障是指系統(tǒng)中部分元器件功能失效而導致整個系統(tǒng)功能惡化的事件。

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

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

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

那我們?yōu)槭裁匆龉收媳O(jiān)控與告警系統(tǒng)呢？

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

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

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

監(jiān)控和告警的目標則是一致的，即：

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

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

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

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

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

1. 故障監(jiān)控與告警系統(tǒng)的基礎

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

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

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

2. 故障監(jiān)控的類型

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

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

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

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

3. 故障告警的規(guī)則和策略

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

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

舉例如下：

比方說針對網(wǎng)絡故障的告警，則對應的監(jiān)控項為網(wǎng)絡速度，那么創(chuàng)建一個告警規(guī)則需要定義如下信息：

• 告警名稱：網(wǎng)絡故障告警
• 告警指標：網(wǎng)絡速度
• 告警條件：網(wǎng)絡速度小于20kb/s
• 統(tǒng)計時間：30分鐘
• 發(fā)生次數(shù)：3次

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

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

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

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

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

三、故障監(jiān)控和告警系統(tǒng)總結

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

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

來源：機房動力環(huán)境監(jiān)控 http://dvdvideogroup.com   本文采集于網(wǎng)絡，如有問題有聯(lián)系刪除