一、背景
一套監(jiān)控系統(tǒng)檢測(cè)和告警是密不可分的，檢測(cè)用來發(fā)現(xiàn)異常，告警用來將問題信息發(fā)送給相應(yīng)的人。vivo監(jiān)控系統(tǒng)1.0時(shí)代各個(gè)監(jiān)控系統(tǒng)分別維護(hù)一套計(jì)算、存儲(chǔ)、檢測(cè)、告警收斂邏輯，這種架構(gòu)下對(duì)底層數(shù)據(jù)融合非常不利，也就無法實(shí)現(xiàn)監(jiān)控系統(tǒng)更廣泛場(chǎng)景的應(yīng)用，所以需要進(jìn)行整體規(guī)劃，重新對(duì)整個(gè)監(jiān)控系統(tǒng)架構(gòu)進(jìn)行調(diào)整，在這樣的背景下統(tǒng)一監(jiān)控的目標(biāo)被確立。
以前監(jiān)控被劃分為基礎(chǔ)監(jiān)控、通用監(jiān)控、調(diào)用鏈、日志監(jiān)控、撥測(cè)監(jiān)控等幾大系統(tǒng)，統(tǒng)一監(jiān)控的目標(biāo)是將各個(gè)監(jiān)控指標(biāo)數(shù)據(jù)進(jìn)行統(tǒng)一計(jì)算、統(tǒng)一存儲(chǔ)、統(tǒng)一檢測(cè)、統(tǒng)一告警、統(tǒng)一展示。這里不作贅述，后面會(huì)出一期vivo監(jiān)控系統(tǒng)演進(jìn)的文章進(jìn)一步說明。
上面我們說了監(jiān)控統(tǒng)一的大背景。以前各個(gè)監(jiān)控系統(tǒng)會(huì)各自進(jìn)行告警收斂、消息組裝等工作，為了減少冗余，需要將收斂等工作由一個(gè)服務(wù)統(tǒng)一做處理，與此同時(shí)告警中心平臺(tái)也到了更新迭代的階段，這樣就需要建設(shè)一個(gè)對(duì)內(nèi)部各業(yè)務(wù)統(tǒng)一提供告警收斂、消息組裝、告警發(fā)送的告警平臺(tái)，有了這個(gè)構(gòu)想，我們準(zhǔn)備將各系統(tǒng)告警收斂能力與告警發(fā)送能力下沉，將統(tǒng)一告警服務(wù)做成一個(gè)與各監(jiān)控服務(wù)解偶的通用服務(wù)。
二、現(xiàn)狀分析
對(duì)于1.0時(shí)代的監(jiān)控系統(tǒng)來說，如圖1所示各個(gè)監(jiān)控系統(tǒng)要先進(jìn)行告警收斂，然后分別和老的告警中心進(jìn)行對(duì)接，才能將告警消息發(fā)送出來。每一套系統(tǒng)都要多帶帶進(jìn)行維護(hù)一套規(guī)則，有很多重復(fù)功能建設(shè)，而實(shí)際這些功能具有高度通用性，完全可以建立合理模型對(duì)異常檢測(cè)服務(wù)生成的異常進(jìn)行統(tǒng)一處理，從而生成問題，然后進(jìn)行統(tǒng)一的消息組裝，最后發(fā)送告警消息。
?(圖1?老監(jiān)控系統(tǒng)告警流程圖）
在監(jiān)控系統(tǒng)中一個(gè)異常從被檢測(cè)出來到最終發(fā)出告警有幾個(gè)重要概念：
異常
在一個(gè)檢測(cè)窗口(窗口大小可以自定義)，一個(gè)或幾個(gè)指標(biāo)值達(dá)到檢測(cè)規(guī)則定義的異常閾值，就產(chǎn)生一個(gè)異常。如圖2所示，檢測(cè)規(guī)則定義當(dāng)指標(biāo)值在一個(gè)檢測(cè)窗口為6的檢測(cè)周期內(nèi)，有3個(gè)數(shù)據(jù)點(diǎn)超過閾值就認(rèn)為有異常，我們簡(jiǎn)稱這個(gè)檢測(cè)規(guī)則為6-3，如圖所示第一個(gè)檢測(cè)窗口內(nèi)(藍(lán)色虛線筐內(nèi))只有6和7兩個(gè)點(diǎn)的指標(biāo)值超過閾值(95)，不滿足6-3的條件，所以第一個(gè)檢測(cè)窗口沒有異常。在第二個(gè)檢測(cè)窗口內(nèi)(綠色虛線框內(nèi))有6、7、8三個(gè)點(diǎn)的指標(biāo)值超過閾值(95)，所以第二個(gè)窗口就是一個(gè)異常。
問題
一個(gè)連續(xù)的周期內(nèi)產(chǎn)生的所有同類異常的集合，我們稱之為問題。如圖2所示，第二個(gè)檢測(cè)窗口就是一個(gè)異常，同時(shí)這個(gè)異常也會(huì)對(duì)應(yīng)有一個(gè)問題A，如果第三個(gè)檢測(cè)窗口也是一個(gè)異常，那么這個(gè)異常對(duì)應(yīng)的問題也是A，所以問題和異常是一對(duì)多的關(guān)系。
告警
當(dāng)一個(gè)問題通過告警系統(tǒng)將消息以短信、電話、郵件等方式告知給用戶時(shí)，我們稱之為一條告警。
恢復(fù)
當(dāng)問題對(duì)應(yīng)的異常不滿足檢測(cè)規(guī)則定義的異常條件時(shí)，就認(rèn)為所有異常都恢復(fù)了，同時(shí)問題也認(rèn)為恢復(fù)了，恢復(fù)也會(huì)發(fā)送相應(yīng)的恢復(fù)通知。
?(圖2?時(shí)序數(shù)據(jù)異常檢測(cè)原理圖）
三、衡量指標(biāo)
一個(gè)系統(tǒng)我們?nèi)绾魏饬克暮脡?，如何提升它，如何管理它？管理學(xué)大師彼得·德魯克曾說“你如果無法度量它，就無法管理它(If you can’t measure it, you can’t manage it)”。從這里可以看出，如果想全面管理提升一個(gè)系統(tǒng)，就需要先對(duì)它的各項(xiàng)性能指標(biāo)有一個(gè)衡量，知道它的薄弱點(diǎn)在哪里，找到病癥所在才能對(duì)癥下藥。
?（圖3?運(yùn)維指標(biāo)時(shí)間節(jié)點(diǎn)關(guān)系圖）
圖3是監(jiān)控系統(tǒng)運(yùn)營(yíng)指標(biāo)和對(duì)應(yīng)時(shí)間節(jié)點(diǎn)關(guān)系圖，主要體現(xiàn)了MTTD、MTTA、MTTF、MTTR、MTBF等指標(biāo)與時(shí)間節(jié)點(diǎn)的對(duì)應(yīng)關(guān)系，這些指標(biāo)對(duì)于提升系統(tǒng)性能，幫助運(yùn)維團(tuán)隊(duì)及早發(fā)現(xiàn)問題有很高的參考價(jià)值。業(yè)界有很多云告警平臺(tái)也很注重這些指標(biāo)，下面我們著重介紹一下MTTA、MTTR這兩個(gè)和告警平臺(tái)關(guān)系緊密的指標(biāo)：
MTTA(Mean time to acknowledge,平均應(yīng)答時(shí)間)：
（圖4 MTTA計(jì)算公式）
t[i] -- 監(jiān)控系統(tǒng)運(yùn)行期間第i個(gè)服務(wù)出現(xiàn)問題后運(yùn)維團(tuán)隊(duì)或者研發(fā)人員響應(yīng)問題的時(shí)間；
- r[i] -- 監(jiān)控系統(tǒng)運(yùn)行期間第i個(gè)服務(wù)出現(xiàn)問題的總次數(shù)。
平均應(yīng)答時(shí)間是運(yùn)維團(tuán)隊(duì)或者研發(fā)團(tuán)隊(duì)響應(yīng)所有問題所花費(fèi)的平均時(shí)間。MTTA度量標(biāo)準(zhǔn)用于衡量運(yùn)維團(tuán)隊(duì)或研發(fā)團(tuán)隊(duì)的響應(yīng)能力和警報(bào)系統(tǒng)的效率。通過跟蹤和最小化MTTA，項(xiàng)目管理團(tuán)隊(duì)可以優(yōu)化流程，提高問題解決效率，保障服務(wù)可用性，提升用戶滿意度[1]。
MTTR(Mean Time To Repair,平均維修時(shí)間)：
（圖5 MTTR計(jì)算公式[2]）
t[ri] -- 監(jiān)控系統(tǒng)運(yùn)行期間第i個(gè)服務(wù)出現(xiàn)r次告警后服務(wù)恢復(fù)正常狀態(tài)的總時(shí)間
- r[i] -- 監(jiān)控系統(tǒng)運(yùn)行期間第i個(gè)服務(wù)出現(xiàn)告警的總次數(shù)
平均修復(fù)時(shí)間（MTTR）是修復(fù)系統(tǒng)并將其恢復(fù)到正常功能所需的平均時(shí)間。運(yùn)維或研發(fā)人員開始處理異常，MTTR便開始計(jì)算，并且一直進(jìn)行到被中斷的服務(wù)完全恢復(fù)（包括所需的任何測(cè)試時(shí)間）為止。在IT服務(wù)管理行業(yè)中，MTTR中的R并不總是表示維修。它也可以表示恢復(fù)，響應(yīng)或解決。盡管這些指標(biāo)都對(duì)應(yīng)MTTR，但是它們都有各自的含義，因此，要弄清楚要使用哪個(gè)MTTR，有助于我們更好的分析理解問題。讓我們簡(jiǎn)要地看一下它們各自的含義：
1）平均恢復(fù)時(shí)間(Mean time to recovery)是從系統(tǒng)告警中恢復(fù)所需的平均時(shí)間。這涵蓋了從服務(wù)異常導(dǎo)致告警到恢復(fù)正常的整個(gè)過程。MTTR是衡量整個(gè)恢復(fù)過程速度的指標(biāo)。
2）平均響應(yīng)時(shí)間(Mean time to respond)表示從出現(xiàn)第一個(gè)告警開始到系統(tǒng)從故障中恢復(fù)到正常狀態(tài)所需的平均時(shí)間，不包括告警系統(tǒng)中的任何延遲。該MTTR通常用于網(wǎng)絡(luò)安全中，以衡量團(tuán)隊(duì)緩解系統(tǒng)攻擊的效率。
3）平均解決時(shí)間(Mean time to resolve)表示完全解決系統(tǒng)故障所花費(fèi)的平均時(shí)間，包括檢測(cè)故障、診斷問題以及確保故障不再發(fā)生來解決問題所需的時(shí)間。此 MTTR 指標(biāo)主要用于衡量不可預(yù)見事件的解決過程，而不是服務(wù)請(qǐng)求。
提升 MTTA 的核心是找對(duì)人、找到人[3]，只有在最短的時(shí)間內(nèi)找對(duì)能處理問題的人才能有效提升MTTR。通常在生產(chǎn)實(shí)踐過程中我們會(huì)遇到“告警泛濫”的問題，大量的告警出現(xiàn)時(shí)需要運(yùn)維人員或者開發(fā)同學(xué)去解決，對(duì)于應(yīng)激敏感的同學(xué)來說很容易出現(xiàn)“狼來了”的現(xiàn)象，只要收到告警就會(huì)很緊張，同時(shí)當(dāng)大量的告警信息頻發(fā)騷擾我們運(yùn)維人員，會(huì)引發(fā)告警疲勞，體現(xiàn)為不重要的事件太多，最根本的問題較少，頻繁處理普通事件，重要的信息淹沒在汪洋大海中。[4]
（圖6 告警泛濫問題圖[5]）
四、功能設(shè)計(jì)
通過上面兩個(gè)重要指標(biāo)的分析，我們總結(jié)出要從告警數(shù)量、告警收斂、告警升級(jí)等方面著手，減少告警發(fā)送的數(shù)量，提升告警準(zhǔn)確性，最終提升解決問題的效率，降低問題恢復(fù)時(shí)長(zhǎng)。下面我們從系統(tǒng)和功能層面說明如何降低告警量，把真正有價(jià)值的告警信息發(fā)送到用戶手中。本文也將重點(diǎn)圍繞告警消息收斂進(jìn)行講解。
從圖1中可以看出各個(gè)監(jiān)控系統(tǒng)中都有很多重復(fù)的功能模塊，所以針對(duì)這些功能模塊我們可以將其抽離出來，如圖7所示將告警收斂、告警屏蔽、告警升級(jí)等能力統(tǒng)一建設(shè)在統(tǒng)一告警服務(wù)中。這種架構(gòu)下統(tǒng)一告警服務(wù)與檢測(cè)相關(guān)服務(wù)完全解耦，在能力上具有一定的通用性。例如其它有告警或消息收斂需求的業(yè)務(wù)團(tuán)隊(duì)想接入統(tǒng)一告警，統(tǒng)一告警要能滿足消息收斂發(fā)送的需求，同時(shí)也要滿足消息直接發(fā)送的需求。統(tǒng)一告警會(huì)提供靈活可配置的消息發(fā)送方式，提供簡(jiǎn)單、多樣的功能滿足各類需求。
（圖7 統(tǒng)一告警系統(tǒng)結(jié)構(gòu)圖）
4.1 告警收斂
對(duì)于告警平臺(tái)每天會(huì)產(chǎn)生數(shù)以萬計(jì)的告警，這些告警對(duì)于運(yùn)維或開發(fā)人員都需要去分析、甄別優(yōu)先級(jí)、并處理故障。數(shù)以萬計(jì)的告警如果不加收斂每條異常都發(fā)送告警，勢(shì)必會(huì)增大運(yùn)維人員的工作壓力，當(dāng)然也不是所有的告警都需要并且有必要發(fā)送給運(yùn)維人員進(jìn)行處理。所以我們需要對(duì)告警通過多種手段進(jìn)行收斂，下面我們從四個(gè)方面介紹一下如何進(jìn)行告警收斂。
首次告警等待
當(dāng)一個(gè)異常產(chǎn)生之后我們不會(huì)立即去做告警，而是通過等待一段時(shí)間才會(huì)去做告警發(fā)送，一般這個(gè)時(shí)間可以通過系統(tǒng)自定義，這個(gè)值如果太大就會(huì)影響告警延遲，太小不能提升告警合并效果。例如首次告警等待時(shí)間為5s，當(dāng)一個(gè)服務(wù)下節(jié)點(diǎn)1出現(xiàn)A指標(biāo)異常，5s內(nèi)節(jié)點(diǎn)2也出現(xiàn)了A指標(biāo)異常，那么發(fā)送告警時(shí)節(jié)點(diǎn)1和節(jié)點(diǎn)2會(huì)被合并到一起發(fā)送告警通知。
告警間隔
問題在沒有恢復(fù)前，系統(tǒng)會(huì)根據(jù)告警間隔的配置每隔一段時(shí)間發(fā)送一條告警信息，告警間隔用來控制告警發(fā)送的頻率。
異常收斂維度
異常收斂維度用來將同個(gè)維度下的異常合并在一起。例如同個(gè)節(jié)點(diǎn)路徑A下，通過同一個(gè)檢測(cè)規(guī)則產(chǎn)生的異常，會(huì)在告警發(fā)送的時(shí)候根據(jù)配置的異常收斂維度合并在一起。
消息合并維度
當(dāng)多個(gè)異常收斂成一個(gè)問題，在發(fā)送告警的時(shí)候會(huì)涉及到消息合并，消息合并維度就是用來指定哪些維度可以合并?？赡苓@樣理解有些晦澀，我們可以通過圖8看一下從異常到消息的轉(zhuǎn)換過程。
假如一個(gè)異常有兩個(gè)維度名字和性別，當(dāng)這兩個(gè)異常經(jīng)過統(tǒng)一告警，我們會(huì)根據(jù)配置的收斂策略進(jìn)行合并，從圖中我們可以看到性別被定義為異常收斂維度，通常異常收斂維度的選擇一定是兩個(gè)或兩個(gè)以上具有相同的屬性的異常，這樣在消息合并后只取相同屬性的同一個(gè)值，對(duì)應(yīng)到示例圖，我們會(huì)將${sex}占位符替換成男。而名字是被定義為告警合并維度，就表示所有異常中名字是都要展示在消息文本中，所以在消息合并的時(shí)候我們會(huì)將${name}占位符對(duì)應(yīng)的信息一一拼接在消息文本中。
（圖8 消息文本替換示意圖?）
4.2 告警認(rèn)領(lǐng)
當(dāng)出現(xiàn)告警后如果有人認(rèn)領(lǐng)了該告警，那么后續(xù)相同告警只會(huì)發(fā)送給告警認(rèn)領(lǐng)人。告警認(rèn)領(lǐng)主要是為了解決告警有人跟進(jìn)后，減少將告警發(fā)給其他人員，也能從一定程度上解決告警被重復(fù)處理的問題。被認(rèn)領(lǐng)的告警可以取消認(rèn)領(lǐng)。
4.3 告警屏蔽
對(duì)于同一個(gè)問題，可以設(shè)置告警屏蔽，后續(xù)如果有該問題對(duì)應(yīng)的告警產(chǎn)生，那么將不會(huì)被發(fā)送出去。告警屏蔽能減少故障在定位解決過程中，或者服務(wù)在發(fā)版變更過程中造成的告警，能有效減少無效告警對(duì)運(yùn)維人員造成的困擾，屏蔽可以設(shè)置為周期性的，也可以設(shè)置為屏蔽某一時(shí)段，當(dāng)然也可以取消屏蔽。
4.4 告警回調(diào)
當(dāng)告警規(guī)則配置了回調(diào)，那么當(dāng)產(chǎn)生告警，就會(huì)調(diào)用回調(diào)接口，使服務(wù)或業(yè)務(wù)恢復(fù)正常。告警回調(diào)的目的是當(dāng)某個(gè)服務(wù)有告警產(chǎn)生，希望系統(tǒng)能夠通過一些自動(dòng)化的配置，使服務(wù)恢復(fù)到正常狀態(tài)，縮短故障恢復(fù)的時(shí)間，也能夠緊急情況下第一時(shí)間快速恢復(fù)服務(wù)。
4.5 誤告標(biāo)注
對(duì)于一個(gè)問題，用戶可以通過誤告標(biāo)注備注該異常是否為誤告警。誤告標(biāo)注的主要目的是通過標(biāo)注讓系統(tǒng)開發(fā)人員知道異常檢測(cè)過程中，哪寫點(diǎn)還需要提升優(yōu)化，提高告警的準(zhǔn)確性，為用戶提供真實(shí)有效的告警提供保障。
4.6 告警升級(jí)
當(dāng)告警發(fā)生一定時(shí)間仍沒有恢復(fù)，那么系統(tǒng)就會(huì)根據(jù)配置自動(dòng)進(jìn)行告警升級(jí)處理，然后將告警升級(jí)信息通過配置發(fā)送給對(duì)應(yīng)的人員。告警升級(jí)一定程度上是為了縮短MTTA，當(dāng)告警長(zhǎng)時(shí)間未恢復(fù)，可以認(rèn)為故障沒有及時(shí)得到響應(yīng)，這時(shí)就需要更高級(jí)別的人員介入處理。
如圖9所示，每天告警系統(tǒng)會(huì)發(fā)送大量的告警，當(dāng)然這些告警會(huì)分別發(fā)送給不同服務(wù)的告警接收人。告警并不是越多越好，而是應(yīng)該第一時(shí)間準(zhǔn)確反映出服務(wù)的異常情況，所以如何提升有效告警，提高告警準(zhǔn)確性，減少告警量至關(guān)重要。通過以上系統(tǒng)設(shè)計(jì)和功能設(shè)計(jì)能夠有效減少重復(fù)告警發(fā)送。
（圖9 主機(jī)監(jiān)控告警次數(shù)圖）
五、架構(gòu)設(shè)計(jì)
上面我們從系統(tǒng)和功能層名講解了如何針對(duì)老架構(gòu)下存在的各種問題進(jìn)行解決，那么對(duì)于這個(gè)構(gòu)想我們應(yīng)該用一套什么架構(gòu)來實(shí)現(xiàn)。
下面我們看下如何設(shè)計(jì)這套架構(gòu)。統(tǒng)一告警作為整個(gè)監(jiān)控最后一環(huán)，既要滿足告警發(fā)送能力也要滿足業(yè)務(wù)服務(wù)發(fā)送通知的需求，所以統(tǒng)一告警的各種能力要具有通用性。統(tǒng)一告警服務(wù)要做到與其它服務(wù)低耦合，尤其是與已有監(jiān)控系統(tǒng)做到解偶，這樣才能真正把通用能力釋放出來。服務(wù)要能做到根據(jù)業(yè)務(wù)場(chǎng)景的不同適配不同的業(yè)務(wù)邏輯，比如有的業(yè)務(wù)需要做告警收斂，有的業(yè)務(wù)不需要，那么服務(wù)要提供靈活的接入方式以適用業(yè)務(wù)需要。
如圖10所示，統(tǒng)一告警核心邏輯由收斂服務(wù)實(shí)現(xiàn)，收斂服務(wù)可以消費(fèi)kafka中的異常，也可以通過RestFul接口接收推送過來的異常，異常會(huì)先經(jīng)過異常處理生成一個(gè)問題，然后將問題和異常存入MySql庫(kù)，經(jīng)過告警收斂模塊問題會(huì)被推送到Redis延時(shí)隊(duì)列中，延時(shí)隊(duì)列會(huì)用來控制消息出隊(duì)時(shí)間，消息從隊(duì)列取出之后會(huì)進(jìn)行文本組裝等操作，最后會(huì)通過配置發(fā)送出去。
（圖10 統(tǒng)一告警架構(gòu)圖）
配置管理服務(wù)用來管理應(yīng)用、事件、告警等配置信息，元數(shù)據(jù)同步服務(wù)用來從其它服務(wù)同步告警收斂所需的元數(shù)據(jù)。
六、核心實(shí)現(xiàn)
統(tǒng)一告警的核心是告警收斂，收斂的目的就是減少發(fā)送重復(fù)的告警消息，避免因?yàn)榇罅康母婢瘜?duì)于告警接收人造成告警麻痹。
前文已經(jīng)說到使用延時(shí)隊(duì)列做告警收斂，延時(shí)隊(duì)列在電商和支付項(xiàng)目中使用較多，比如商品下單后10分鐘未支付就要自動(dòng)取消訂單。在告警系統(tǒng)中使用延時(shí)隊(duì)列主要目的是，在一定的時(shí)間內(nèi)盡可能多的將同一個(gè)問題對(duì)應(yīng)的異常合并在一起，減少告警發(fā)送的數(shù)量。舉個(gè)例，如果一個(gè)服務(wù)A有三個(gè)節(jié)點(diǎn)，當(dāng)發(fā)生異常時(shí)，一般情況下每個(gè)節(jié)點(diǎn)的異常都會(huì)生成一條告警發(fā)送出去，但是經(jīng)過告警收斂時(shí)候我們可以將三個(gè)節(jié)點(diǎn)的告警合并，由一條告警做通知。
延時(shí)隊(duì)列有很多種方式實(shí)現(xiàn)，這里我們選擇了Redis實(shí)現(xiàn)延時(shí)隊(duì)列，選用 Redis 延時(shí)隊(duì)列主要的原因就是其支持高性能的 score 排序，同時(shí) Redis 的持久化特性，保證了消息的消費(fèi)和存貯問題。
如圖11所示，一個(gè)問題通過一系列校驗(yàn)去重之后放入redis延時(shí)隊(duì)列，隊(duì)列中到期時(shí)間最小的問題會(huì)被排到最前面，同時(shí)有一個(gè)監(jiān)聽任務(wù)不斷查看隊(duì)列中是否有過期的任務(wù)，如果有過期的任務(wù)會(huì)被取出，取出的消息會(huì)經(jīng)過消息組裝等操作最終形成一條消息文本，然后根據(jù)配置通過不同的通道發(fā)送出去。
（圖11 延時(shí)任務(wù)執(zhí)行原理圖[6]）
七、未來展望
基于統(tǒng)一告警服務(wù)定位來看，告警服務(wù)要能簡(jiǎn)單、高效、準(zhǔn)確的告訴運(yùn)維或者開發(fā)人員，哪里有故障需要去處理。所以對(duì)于后續(xù)服務(wù)的建設(shè)，應(yīng)該考慮如何進(jìn)一步減少人為的配置，增強(qiáng)告警智能化收斂的能力，同時(shí)還要增強(qiáng)根因定位的能力，以上通過AI的加持能夠很好的解決此類問題。目前各大廠商都在向著AIOps探索前進(jìn)，并且已經(jīng)有一些產(chǎn)品投入使用，但是AIOps何時(shí)大規(guī)模落地，就目前來看還需要一段時(shí)間。相較于AI的使用，當(dāng)前最緊迫的就是讓統(tǒng)一告警串聯(lián)起上下游服務(wù)，從而打通數(shù)據(jù)，為數(shù)據(jù)流轉(zhuǎn)鋪平道路，增強(qiáng)服務(wù)的自動(dòng)化程度，并且支持從更高維度實(shí)現(xiàn)告警發(fā)送，為故障的發(fā)現(xiàn)和解決提供更準(zhǔn)確的信息。
八、參考資料
[1]What are MTTR, MTBF, MTTF, and MTTA? A guide to Incident Management metrics
[3]運(yùn)維不容錯(cuò)過的4個(gè)關(guān)鍵指標(biāo)！
[4]PIGOSS TOC 智慧服務(wù)中心讓告警管理更智能
[5]大規(guī)模智能告警收斂與告警根因技術(shù)實(shí)踐[EB/OL].
?作者：vivo互聯(lián)網(wǎng)服務(wù)器團(tuán)隊(duì)-Chen Ningning
