王金鋒

（上海電科智能系統(tǒng)股份有限公司）

1 前言

在綜合管廊集成監(jiān)控平臺(tái)運(yùn)營(yíng)中，系統(tǒng)實(shí)時(shí)或定期采集管廊廊體安全、氣體環(huán)境安全以及入廊管線運(yùn)營(yíng)、風(fēng)機(jī)水泵設(shè)備等安全指標(biāo)。一旦相應(yīng)的指標(biāo)出現(xiàn)異?；蜻_(dá)到報(bào)警閾值，系統(tǒng)會(huì)發(fā)起實(shí)時(shí)報(bào)警事件。但是在上海滴水湖北島7km的管廊工程實(shí)際運(yùn)營(yíng)管理中，運(yùn)維工程師們白天平均12min就會(huì)接收一次短信報(bào)警，在夜間則是平均18min一次，而實(shí)際數(shù)據(jù)統(tǒng)計(jì)發(fā)現(xiàn)，有效短信報(bào)警占比不到15%。因此短信報(bào)警的冗余度是相當(dāng)高的，已經(jīng)造成了報(bào)警風(fēng)暴。

報(bào)警是為了預(yù)防事故發(fā)生、發(fā)現(xiàn)問(wèn)題根源，發(fā)展和蔓延。一旦形成報(bào)警風(fēng)暴，運(yùn)維值班人員必將迷失在報(bào)警信息的海洋了，從而可能延誤對(duì)異常根源的排查和判定，錯(cuò)失事故處理的最佳時(shí)機(jī)，影響管廊運(yùn)行安全，甚至釀成更大的生產(chǎn)管理事故。

2 報(bào)警風(fēng)暴形成的原因

2.1 報(bào)警重復(fù)度高

首先報(bào)警策略執(zhí)行按周期計(jì)算，因此會(huì)持續(xù)產(chǎn)生重復(fù)報(bào)警，部分策略甚至?xí)?dǎo)致持續(xù)報(bào)警達(dá)1h以上。更嚴(yán)重的情形是，一次故障可能引發(fā)多個(gè)相關(guān)策略報(bào)警。比如一個(gè)防火分區(qū)出現(xiàn)有毒氣體，本防火區(qū)首先報(bào)警，然后實(shí)例層面報(bào)警，隨著空氣流通，接著緊鄰的防火區(qū)也會(huì)報(bào)警。

2.2 報(bào)警關(guān)注度不足

報(bào)警關(guān)注度是指接到報(bào)警信息后相應(yīng)人員的及時(shí)處理動(dòng)作——把報(bào)警發(fā)送后有實(shí)際處理的比例作為報(bào)警關(guān)注度的度量指標(biāo)，發(fā)現(xiàn)實(shí)際關(guān)注度并不高，而在夜間短信報(bào)警關(guān)注率則低至25%。但事實(shí)上夜間短信報(bào)警的級(jí)別一般都是比較高的。這就意味著很多報(bào)警策略的發(fā)送方式和實(shí)際的報(bào)警等級(jí)已經(jīng)相違背了。這是因?yàn)閳?bào)警的關(guān)注度隨著業(yè)務(wù)發(fā)展發(fā)生變化，但是這些關(guān)注度的變化沒(méi)有及時(shí)的在報(bào)警系統(tǒng)中修改，導(dǎo)致已經(jīng)變得不那么重要緊急的報(bào)警，卻還在以短信的形式給值班工程師發(fā)送報(bào)警。

2.3 報(bào)警接收人冗余

每個(gè)報(bào)警策略平均有3個(gè)接收人，部分報(bào)警甚至超過(guò)了7個(gè)。報(bào)警策略的接收人往往會(huì)填寫(xiě)了運(yùn)維團(tuán)隊(duì)中的所有人，但實(shí)際值班人只有一個(gè)人，大家按周期輪轉(zhuǎn)。因此，對(duì)于一個(gè)特定的報(bào)警，大部分在列人員是不需要即時(shí)關(guān)注的。

2.4 報(bào)警有效性不足

超過(guò)88%以上的報(bào)警都是單實(shí)例報(bào)警，40%以上只需要簡(jiǎn)單的處理即可恢復(fù)，比如平臺(tái)本身磁盤(pán)打滿或者內(nèi)存泄露等。因此我們?cè)谶\(yùn)維系統(tǒng)中增加了自愈機(jī)制，自愈成功后，只需記錄報(bào)警日志即可。

3 報(bào)警信息管理優(yōu)化

3.1 報(bào)警合并策略

報(bào)警合并對(duì)很多做監(jiān)控系統(tǒng)常用的優(yōu)化措施，相關(guān)文獻(xiàn)都提到了這個(gè)過(guò)程，但大多數(shù)提及的報(bào)警合并都是將某個(gè)時(shí)間窗口內(nèi)的報(bào)警簡(jiǎn)單的合并成為一條，此舉對(duì)削減報(bào)警數(shù)量固然有效，但不利于值班工程師進(jìn)行故障診斷。我們希望把若干描述同一故障的報(bào)警合并在一起，讓值班工程師可以快速捕捉到故障本質(zhì)，甚至故障根因，而并非一味的削減報(bào)警量。

最簡(jiǎn)單的報(bào)警合并方法可以基于報(bào)警策略的自然屬性，包含策略名或者部署維度等。當(dāng)合并的內(nèi)容過(guò)多時(shí)，將最主要的報(bào)警或者報(bào)警的總結(jié)匯總到短信內(nèi)容里面，具體的每一條細(xì)節(jié)報(bào)警、報(bào)警起始結(jié)束時(shí)間、報(bào)警持續(xù)時(shí)間、報(bào)警配置內(nèi)容等細(xì)節(jié)信息都會(huì)在短鏈的頁(yè)面中展示。

3.2 報(bào)警合并的機(jī)制

一個(gè)報(bào)警產(chǎn)生以后，我們先把這個(gè)報(bào)警插入一個(gè)發(fā)送等待隊(duì)列而非立即發(fā)送。報(bào)警產(chǎn)生后先插入等待隊(duì)列里面去，在隊(duì)列里等進(jìn)行延遲計(jì)時(shí)，當(dāng)達(dá)到了能夠容忍的延遲時(shí)間以后，我們?cè)诘却?duì)列中找到可以和該報(bào)警一起合并發(fā)送的報(bào)警，根據(jù)實(shí)際的合并維度渲染成不同的報(bào)警短信內(nèi)容，然后合并成一條報(bào)警短信發(fā)送。

3.3 關(guān)聯(lián)策略的報(bào)警合并

某個(gè)模塊的出現(xiàn)問(wèn)題，往往會(huì)引發(fā)上游或者下游模塊也一并報(bào)警。假設(shè)模塊A調(diào)用了模塊B，當(dāng)模塊B出現(xiàn)問(wèn)題的時(shí)候，很顯然模塊A和模塊B都會(huì)產(chǎn)生報(bào)警。

歷史上每次B模塊出現(xiàn)同樣的問(wèn)題的時(shí)候都會(huì)導(dǎo)致A模塊有類似的報(bào)警，換言之，若歷史上A模塊的策略rule1和B模塊的rule2經(jīng)常同時(shí)報(bào)警，那么A模塊的策略rule1和B模塊的策略rule2就可能存在關(guān)聯(lián)。因此我們可以挖掘歷史報(bào)警數(shù)據(jù)中的關(guān)聯(lián)關(guān)系，即關(guān)聯(lián)的報(bào)警策略列表。

使用常見(jiàn)關(guān)聯(lián)分析算法挖掘頻繁項(xiàng)集（歷史上經(jīng)常在一起出現(xiàn)的報(bào)警策略）和關(guān)聯(lián)規(guī)則（報(bào)警策略之間存在很強(qiáng)的關(guān)系）。下面定義報(bào)警策略的頻繁出現(xiàn)或是否存在關(guān)聯(lián)：一個(gè)項(xiàng)集的支持度計(jì)數(shù)被定義為該項(xiàng)集出現(xiàn)的次數(shù)，區(qū)別于傳統(tǒng)的支持度是因?yàn)闅v史報(bào)警數(shù)據(jù)產(chǎn)生的數(shù)據(jù)往往較多，而實(shí)際項(xiàng)集數(shù)據(jù)出現(xiàn)的比較稀疏，意味著支持度的分母巨大，分子卻很小。

置信度是針對(duì)一條關(guān)聯(lián)規(guī)則X：rulem→Y：rulen而言定義的，代表了X：rulem導(dǎo)致Y：rulen發(fā)生的可能的概率。

支持度計(jì)數(shù)S_count(X：rulem)=以X：rulem開(kāi)頭的transaction的數(shù)量

支 持 度 計(jì) 數(shù)S_count(X：rulem →Y：rulen)=以X：rulem開(kāi)頭，并且包含Y：rulen的transaction的數(shù)量置信度c（X→Y）計(jì)算公式如下：

支持度和置信度超過(guò)一定數(shù)值即為所需的關(guān)聯(lián)規(guī)則。按照這樣的規(guī)則，在等待發(fā)送隊(duì)列中，當(dāng)某個(gè)報(bào)警發(fā)送時(shí)在報(bào)警策略關(guān)聯(lián)表中查找等待隊(duì)列中如果包含合并策略，就合并成一條報(bào)警信息發(fā)送。

3.4 報(bào)警關(guān)注度

報(bào)警關(guān)注度是指報(bào)警發(fā)送后有實(shí)際處理的比例，但系統(tǒng)運(yùn)維一段時(shí)間后都會(huì)發(fā)現(xiàn)部分報(bào)警的關(guān)注度遠(yuǎn)低于100%，大多數(shù)情況下并非是值班工程師不盡責(zé)，而是部分報(bào)警策略隨著系統(tǒng)的演化已經(jīng)失效而又沒(méi)有及時(shí)刪除，因此需要我們能夠識(shí)別無(wú)效報(bào)警。

一般地，值班工程師收到一條有效的短信報(bào)警后，會(huì)登錄運(yùn)維系統(tǒng)（包括監(jiān)控系統(tǒng)、預(yù)案系統(tǒng)等）對(duì)報(bào)警進(jìn)行定位、處理，這些行為會(huì)體現(xiàn)在各種運(yùn)維系統(tǒng)的訪問(wèn)日志中。通過(guò)收集這些日志，就可以對(duì)每條報(bào)警的處理情況進(jìn)行分析：如果在收到報(bào)警后的一段時(shí)間內(nèi)訪問(wèn)過(guò)運(yùn)維系統(tǒng)，可以認(rèn)為該報(bào)警得到了關(guān)注，反之就認(rèn)為該報(bào)警沒(méi)有得到關(guān)注。匯總一段時(shí)間后，就能夠篩選出關(guān)注度較低的報(bào)警策略，即為無(wú)效報(bào)警策略。

3.5 報(bào)警自愈機(jī)制

很多報(bào)警都有明確的處理預(yù)案，報(bào)警發(fā)生后，值班工程師登錄機(jī)器或者中控機(jī)執(zhí)行預(yù)案（腳本）就可以完成這類故障的處理。比如，清理磁盤(pán)這類操作，可以完全自動(dòng)處理，無(wú)需人工干預(yù)，就能夠大量節(jié)省人工成本，同時(shí)減少報(bào)警量。因此，監(jiān)控報(bào)警系統(tǒng)提供了報(bào)警回調(diào)機(jī)制，在報(bào)警發(fā)生時(shí)可以回調(diào)預(yù)案處理腳本。

對(duì)于更復(fù)雜的場(chǎng)景，值班工程師往往需要根據(jù)服務(wù)的整體情況來(lái)調(diào)整預(yù)案。例如當(dāng)某個(gè)實(shí)例異常需要重啟的時(shí)候，需要綜合判斷其他實(shí)例的狀態(tài)才能確定是否以及何時(shí)可以重啟該實(shí)例，以免給其他服務(wù)造成損失。這種場(chǎng)景的自愈操作可能是有損的，需要對(duì)服務(wù)整體情況有一個(gè)判斷才可以執(zhí)行預(yù)案，監(jiān)控報(bào)警系統(tǒng)為此提供了一種回調(diào)機(jī)制。在發(fā)生報(bào)警時(shí)，報(bào)警系統(tǒng)會(huì)把相關(guān)的報(bào)警策略、實(shí)例的狀態(tài)都統(tǒng)一發(fā)送給一個(gè)中樞決策服務(wù)，由中樞決策服務(wù)統(tǒng)一做出判斷。

4 結(jié)論

通過(guò)對(duì)現(xiàn)代綜合管廊安全運(yùn)營(yíng)監(jiān)測(cè)報(bào)警子系統(tǒng)的監(jiān)測(cè)報(bào)警數(shù)據(jù)進(jìn)行問(wèn)題梳理，并有針對(duì)性的進(jìn)行的信息優(yōu)化處理。以科學(xué)合理的數(shù)據(jù)管理方式，準(zhǔn)確判定數(shù)據(jù)異常，通過(guò)報(bào)警合并策略及報(bào)警分級(jí)，高效便捷的管理跟蹤報(bào)警事件處理過(guò)程，避免管理過(guò)程中設(shè)備設(shè)施報(bào)警信息的報(bào)警風(fēng)暴，為后續(xù)綜合管廊監(jiān)控運(yùn)營(yíng)優(yōu)化提供參照，提升管廊管理水平。