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

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

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

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

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

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

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

建立多層次和職責劃分的支撐團隊。

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

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

事件單記錄和團隊協(xié)作。

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

大多公司都用了zabbix和nagios、open-falcon等監(jiān)控工具，對硬件、網(wǎng)絡(luò)、應(yīng)用進行監(jiān)控?？赡軙嬖诒O(jiān)控分散問題：

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

如果有多個異地數(shù)據(jù)中心時，可能需要部署多個zabbix和工具。

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

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

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

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

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

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

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

建立一線、二線甚至三線支撐團隊，一線好理解，一般是7x24小時值班的同學們。

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

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

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

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

警告級別：影響范圍和嚴重程度會低一些的故障，處理時長可以長一些。

提醒級別：依次更低。

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

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

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

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

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

排班，7x24小時緊繃狀態(tài)不是誰都能扛得住的，適當輪班緩解下壓力?？梢酝ㄟ^排班機制，白夜班，按周等模式進行輪流。

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

分派升級

排班管理

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

郵件通知，簡單有效，就是不夠及時。

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

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

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

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

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

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

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

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

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

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

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

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

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

機器學習告警合并

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

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

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

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

責任人和責任組，分派到其他團隊或個人，并通知提醒。

事件單

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

On-Call機制建立后，通過告警和事件數(shù)據(jù)分析、建立起以數(shù)據(jù)指標驅(qū)動的團隊文化，有機會和大家分享。

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

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