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

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

1. 什么是故障,？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

舉例如下：

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

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

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

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

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

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

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

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

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

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

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