摘要：如何有效處理緊急事件驅(qū)動(dòng)的工作，成為特別是運(yùn)維主管運(yùn)維工作的關(guān)鍵。通知到位和及時(shí)響應(yīng)。機(jī)器學(xué)習(xí)領(lǐng)域是未來的重要發(fā)展方向，目前我們還在摸索中。機(jī)器學(xué)習(xí)告警合并事件單的處理如果告警量很大，告警后續(xù)處理和跟蹤往往會(huì)依賴于外部團(tuán)隊(duì)部門外或公司外。

編者按]本文作者為陳伯龍，云告警平臺(tái)[OneAlert創(chuàng)始人，著《云計(jì)算與OpenStack》，在IT運(yùn)營(yíng)管理、云計(jì)算方面從業(yè)10多年。

互聯(lián)網(wǎng)技術(shù)的發(fā)展，離不開運(yùn)維支撐工作，沒有零bug的程序，沒有不出問題的系統(tǒng)，問題故障不可怕，可怕的是沒能有序的處理：

突發(fā)緊急事件太多，疲于應(yīng)付，團(tuán)隊(duì)士氣低下，效率不高。

重要事情淹沒在大量事件中，沒有有序跟進(jìn)處理，會(huì)引發(fā)嚴(yán)重業(yè)務(wù)影響。

如何有效處理緊急事件驅(qū)動(dòng)的工作，成為（特別是運(yùn)維主管）運(yùn)維工作的關(guān)鍵。我接觸了大量的各類型公司運(yùn)維，從初創(chuàng)、中小、大型公司，總結(jié)和分享一些大多公司通用的on-call機(jī)制，幫助有序的處理緊急事件：

監(jiān)控告警事件集中化。

建立多層次和職責(zé)劃分的支撐團(tuán)隊(duì)。

通知到位和及時(shí)響應(yīng)。

告警風(fēng)暴關(guān)聯(lián)合并。

事件單記錄和團(tuán)隊(duì)協(xié)作。

基本上都是圍繞人、流程、工具三方面進(jìn)行，參考了ITIL的管理思路，大家感興趣也可以參考下，特別是其中的ITIL V3的運(yùn)營(yíng)管理。

大多公司都用了zabbix和nagios、open-falcon等監(jiān)控工具，對(duì)硬件、網(wǎng)絡(luò)、應(yīng)用進(jìn)行監(jiān)控。可能會(huì)存在監(jiān)控分散問題：

環(huán)境比較復(fù)雜的時(shí)候，可能會(huì)用多個(gè)工具，如cacti監(jiān)控網(wǎng)絡(luò)，zabbix監(jiān)控應(yīng)用和服務(wù)器。

如果有多個(gè)異地?cái)?shù)據(jù)中心時(shí)，可能需要部署多個(gè)zabbix和工具。

部分關(guān)鍵業(yè)務(wù)，需要多帶帶的開發(fā)監(jiān)控腳本／工具進(jìn)行獨(dú)立監(jiān)測(cè)。
如果沒有集中告警機(jī)制，容易出現(xiàn)郵件滿天飛的現(xiàn)象，也很難跟進(jìn)和處理，郵件也容易遺漏。

告警集中化，就是所有的生產(chǎn)監(jiān)控發(fā)現(xiàn)的告警事件集中到一起，這樣我們盯著一個(gè)平臺(tái)就夠了，同樣也容易分析問題，是不是相同和類似原因。

能夠直觀掌握現(xiàn)有環(huán)境的狀況。

發(fā)現(xiàn)事件相關(guān)性的，有些問題有較強(qiáng)關(guān)聯(lián)性的，如網(wǎng)絡(luò)穩(wěn)定性影響主機(jī)，數(shù)據(jù)庫(kù)性能影響業(yè)務(wù)等。

方便跟蹤和后續(xù)的統(tǒng)計(jì)分析。

集中處理，就不用查看各種監(jiān)控工具了，效率更高。

如果監(jiān)控工具單一，集中化不是最必要的，如何有序處理才是最核心的。特別運(yùn)維團(tuán)隊(duì)是3-5人到數(shù)十／百人，就很有必要梳理下支撐流程和響應(yīng)機(jī)制了。

建立一線、二線甚至三線支撐團(tuán)隊(duì)，一線好理解，一般是7x24小時(shí)值班的同學(xué)們。

二線一般是資深工程師，或者是對(duì)應(yīng)的應(yīng)用開發(fā)／測(cè)試同學(xué)。

三線一般是主管或者是外部的廠家，如涉及硬件、IDC機(jī)房等相關(guān)服務(wù)方。

如果管理比較細(xì)一些，還會(huì)進(jìn)行業(yè)務(wù)拆分，形成一個(gè)矩陣，例如一線、二線根據(jù)不同專業(yè)，如負(fù)責(zé)網(wǎng)絡(luò)和負(fù)責(zé)不同應(yīng)用的團(tuán)隊(duì)。
另外還要考慮告警嚴(yán)重的程度級(jí)別，進(jìn)行差異化處理，要求嚴(yán)格的同學(xué)一般會(huì)建立響應(yīng)級(jí)別[1-3]或[1-5]：

嚴(yán)重級(jí)別，如大范圍影響業(yè)務(wù)／終端用戶的，需要及時(shí)處理。一般要求多長(zhǎng)時(shí)間響應(yīng)處理，如3-10分鐘有人響應(yīng)，無響應(yīng)立刻升級(jí)。

警告級(jí)別：影響范圍和嚴(yán)重程度會(huì)低一些的故障，處理時(shí)長(zhǎng)可以長(zhǎng)一些。

提醒級(jí)別：依次更低。

那么問題來了，規(guī)劃和設(shè)計(jì)挺好，如何落地呢？目前看zabbix、nagios、open-falcon等監(jiān)控工具更多是聚焦如何發(fā)現(xiàn)問題，支撐流程屬于處理問題的范疇，或者是說管理范疇，這一點(diǎn)目前市面上合適工具較少：

人肉方式：一個(gè)監(jiān)控班，7x24值班，人為處理和通知。大多運(yùn)營(yíng)商和金融及其他超大規(guī)模公司的管理方式。

技術(shù)實(shí)現(xiàn)方式：通過分派策略、標(biāo)簽識(shí)別、排班機(jī)制等：

通過分派策略、可以進(jìn)行流程的設(shè)計(jì)，根據(jù)級(jí)別、應(yīng)用設(shè)置對(duì)應(yīng)的一、二線負(fù)責(zé)人，以及處理時(shí)限，超時(shí)未響應(yīng)（確認(rèn)告警）自動(dòng)升級(jí)。

標(biāo)簽技巧，如何識(shí)別不同業(yè)務(wù)和應(yīng)用，一般來說可以在告警的標(biāo)題打標(biāo)簽，如HOST等，或者是通過zabbix／nagios的hostgroup, applications等字段打標(biāo)簽。這樣在分派策略就可以進(jìn)行（正則）匹配了。

排班，7x24小時(shí)緊繃狀態(tài)不是誰都能扛得住的，適當(dāng)輪班緩解下壓力。可以通過排班機(jī)制，白夜班，按周等模式進(jìn)行輪流。

接觸過一個(gè)互聯(lián)網(wǎng)金融公司，設(shè)計(jì)了非常規(guī)范化的流程和P0-P5級(jí)別應(yīng)急處理方案，涉及了網(wǎng)絡(luò)、云平臺(tái)、近50個(gè)應(yīng)用研發(fā)團(tuán)隊(duì)。

分派升級(jí)

排班管理

再好的流程和設(shè)計(jì)，當(dāng)時(shí)沒有及時(shí)收到通知和處理，那么就會(huì)很郁悶了，最后一公里問題解決方式：

郵件通知，簡(jiǎn)單有效，就是不夠及時(shí)。

短信方式，需要開發(fā)對(duì)接，目前很多公司都有自己的短信服務(wù)通道。要注意一個(gè)限制：部分運(yùn)營(yíng)商會(huì)限制一天相類似內(nèi)容只能發(fā)送10－30條。

微信、移動(dòng)APP通知，適應(yīng)移動(dòng)大潮。微信方式，好處是人人都有，壞處就是告警消息和正常溝通消息會(huì)混淆。

電話，救命線，電話通知可以應(yīng)對(duì)特別重要的告警，例如晚上嚴(yán)重的電話通知，目前這一點(diǎn)國(guó)內(nèi)也有不少服務(wù)商，需要對(duì)接下。

QQ，釘釘、worktile等協(xié)作類工具，這一點(diǎn)屬于彩蛋性質(zhì)。

還支持幾點(diǎn)：不同級(jí)別、不同時(shí)間段的設(shè)置，例如晚上嚴(yán)重的電話通知，白天工作時(shí)間就不用了。
這里面還存在一個(gè)問題，當(dāng)告警規(guī)模大了后，特別是告警風(fēng)暴的話，很容易撐爆郵箱或者是手機(jī)短信了，所以接下來就聊下告警風(fēng)暴規(guī)避的問題。

這個(gè)問題比較大，基本上有些監(jiān)控工具做了一部分，目前看也是一個(gè)業(yè)界難題，簡(jiǎn)單來說：

靜態(tài)規(guī)則方式，需要知識(shí)經(jīng)驗(yàn)積累，根據(jù)業(yè)務(wù)邏輯梳理出一些父子關(guān)系。簡(jiǎn)單如，出現(xiàn)服務(wù)器Down的告警，肯定該機(jī)器上的業(yè)務(wù)應(yīng)用也會(huì)Down，那么就整理為一條規(guī)則。需要一套告警的過濾引擎，根據(jù)告警字段信息進(jìn)行匹配。

關(guān)聯(lián)關(guān)系分析，依賴CMDB，服務(wù)關(guān)聯(lián)關(guān)系，根據(jù)調(diào)用依賴關(guān)系進(jìn)行告警的根源追溯。CMDB的建設(shè)和維護(hù)是非常困難的事情，數(shù)據(jù)準(zhǔn)確性和實(shí)時(shí)性是決定CMDB效果的根本因素。CMDB國(guó)內(nèi)落地效果理想的很少，只能依賴自動(dòng)化，微服務(wù)、docker、devops大量應(yīng)用讓IT環(huán)境更動(dòng)態(tài)、更復(fù)雜，沒有自動(dòng)化機(jī)制保障是非常困難的。

機(jī)器學(xué)習(xí)方式，相比前兩種方式，機(jī)器學(xué)習(xí)更取巧一些，或者是說應(yīng)該是未來的方向，節(jié)省大量人力物力。

我們目前做了一些嘗試分享下：

時(shí)間序列合并，如同一個(gè)告警信息，每個(gè)幾分鐘發(fā)生一次，就會(huì)合并，直到告警恢復(fù)／關(guān)閉掉。

機(jī)器學(xué)習(xí)合并，包括實(shí)時(shí)計(jì)算和離線計(jì)算，算法方面參考了相似度、決策樹、分類等算法。以相似度來說：首先采集告警的多維度信息，包括時(shí)間、主機(jī)、服務(wù)、分組hostgroups、應(yīng)用applications、標(biāo)簽tags等基本維度信息，計(jì)算不同告警之間相似度，如果達(dá)到閾值，如告警A和告警B有70%相似就關(guān)聯(lián)起來。目前沒有一種算法是最合適的，以相似度為例因?yàn)楦鶕?jù)業(yè)務(wù)不同，各維度的權(quán)重，閾值靈敏度有些差異。例如某些應(yīng)用的機(jī)器名規(guī)范化很高，如portal_mysql_master,portal_mysql_slave1,portal_mysql_slave2之類的，機(jī)器名權(quán)重可以高一些。機(jī)器學(xué)習(xí)領(lǐng)域是未來的重要發(fā)展方向，目前我們還在摸索中。

通知合并，瞬間告警通知量大的情況下，降頻合并發(fā)送通知，如有16條告警未處理。

機(jī)器學(xué)習(xí)告警合并

如果告警量很大，告警后續(xù)處理和跟蹤往往會(huì)依賴于外部團(tuán)隊(duì)（部門外或公司外）。但是監(jiān)控告警粒度太細(xì)了，可能很多告警都是一個(gè)事情。如上面的告警風(fēng)暴中，由于應(yīng)用程序故障，引發(fā)引發(fā)了大量的異常，之后又產(chǎn)生連鎖反應(yīng)，其實(shí)就是一個(gè)事情，只需要處理一個(gè)事情就行。
一般來說一線人員會(huì)采用郵件或者電話方式，直接通知對(duì)應(yīng)負(fù)責(zé)人，但是這個(gè)就很難追蹤和事后分析，所以一套事件管理機(jī)制。
ITIL規(guī)范的事件Incident流程很有參考價(jià)值，感興趣同學(xué)參考下。事件工單需要：

將批量告警轉(zhuǎn)為事件工單，這里包括手動(dòng)轉(zhuǎn)發(fā)和自動(dòng)匹配規(guī)則轉(zhuǎn)發(fā)。

手動(dòng)生成事件工單，一般屬于非告警類觸發(fā)，如人工發(fā)現(xiàn)或用戶投訴等引發(fā)的事件。

事件工單包括影響范圍、嚴(yán)重程度，兩者的交叉矩陣影響到處理的優(yōu)先級(jí)。包括分類、子類、自定義標(biāo)簽，分類和標(biāo)記有助于后續(xù)的統(tǒng)計(jì)分析。

責(zé)任人和責(zé)任組，分派到其他團(tuán)隊(duì)或個(gè)人，并通知提醒。

事件單

影響范圍和緊急程度的交叉矩陣影響到優(yōu)先級(jí)

On-Call機(jī)制建立后，通過告警和事件數(shù)據(jù)分析、建立起以數(shù)據(jù)指標(biāo)驅(qū)動(dòng)的團(tuán)隊(duì)文化，有機(jī)會(huì)和大家分享。

OneAlert 是 OneAPM 旗下產(chǎn)品，是國(guó)內(nèi)第一個(gè) SaaS 模式的云告警平臺(tái)，集成國(guó)內(nèi)外主流監(jiān)控/支撐系統(tǒng)，實(shí)現(xiàn)一個(gè)平臺(tái)上集中處理所有 IT 事件，提升 IT 可靠性。想閱讀更多技術(shù)文章，請(qǐng)?jiān)L問 OneAPM 官方技術(shù)博客。

本文轉(zhuǎn)自 OneAPM 官方博客