一、有關(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è)備正常售賣的事件，包括硬件上的故障，也包括軟件上的故障。

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

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

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

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

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

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

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

• 全面：監(jiān)控與告警的廣度，盡可能多的覆蓋到故障類型
• 及時：數(shù)據(jù)處理和傳遞的時效性，快速的將告警信息暴露出來
• 準(zhǔn)確：保證監(jiān)控和告警信息的準(zhǔn)確性，避免浪費(fèi)相應(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點(diǎn)是做該系統(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)控故障：

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

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

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

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

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

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

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

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

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

那么告警規(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)的拓展性和廣泛使用性，可以及時跟進(jìn)數(shù)據(jù)情況修改和新增相應(yīng)的告警規(guī)則。

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

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

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

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

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

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

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

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