[編者按]本文作者為陳伯龍，云告警平臺OneAlert創(chuàng)始人，著《云計算與OpenStack》，在IT運營管理、云計算方面從業(yè)10多年。
正文
互聯(lián)網(wǎng)技術的發(fā)展，離不開運維支撐工作，沒有零bug的程序，沒有不出問題的系統(tǒng)，問題故障不可怕，可怕的是沒能有序的處理：
突發(fā)緊急事件太多，疲于應付，團隊士氣低下，效率不高。
重要事情淹沒在大量事件中，沒有有序跟進處理，會引發(fā)嚴重業(yè)務影響。
如何有效處理緊急事件驅動的工作，成為（特別是運維主管）運維工作的關鍵。我接觸了大量的各類型公司運維，從初創(chuàng)、中小、大型公司，總結和分享一些大多公司通用的on-call機制，幫助有序的處理緊急事件：
監(jiān)控告警事件集中化。
建立多層次和職責劃分的支撐團隊。
通知到位和及時響應。
告警風暴關聯(lián)合并。
事件單記錄和團隊協(xié)作。
基本上都是圍繞人、流程、工具三方面進行，參考了ITIL的管理思路，大家感興趣也可以參考下，特別是其中的ITIL V3的運營管理。
監(jiān)控告警集中化
大多公司都用了zabbix和nagios、open-falcon等監(jiān)控工具，對硬件、網(wǎng)絡、應用進行監(jiān)控?？赡軙嬖诒O(jiān)控分散問題：
環(huán)境比較復雜的時候，可能會用多個工具，如cacti監(jiān)控網(wǎng)絡，zabbix監(jiān)控應用和服務器。
如果有多個異地數(shù)據(jù)中心時，可能需要部署多個zabbix和工具。
部分關鍵業(yè)務，需要單獨的開發(fā)監(jiān)控腳本／工具進行獨立監(jiān)測。
如果沒有集中告警機制，容易出現(xiàn)郵件滿天飛的現(xiàn)象，也很難跟進和處理，郵件也容易遺漏。
告警集中化，就是所有的生產(chǎn)監(jiān)控發(fā)現(xiàn)的告警事件集中到一起，這樣我們盯著一個平臺就夠了，同樣也容易分析問題，是不是相同和類似原因。
能夠直觀掌握現(xiàn)有環(huán)境的狀況。
發(fā)現(xiàn)事件相關性的，有些問題有較強關聯(lián)性的，如網(wǎng)絡穩(wěn)定性影響主機，數(shù)據(jù)庫性能影響業(yè)務等。
方便跟蹤和后續(xù)的統(tǒng)計分析。
集中處理，就不用查看各種監(jiān)控工具了，效率更高。
建立支撐流程和機制
如果監(jiān)控工具單一，集中化不是最必要的，如何有序處理才是最核心的。特別運維團隊是3-5人到數(shù)十／百人，就很有必要梳理下支撐流程和響應機制了。
建立一線、二線甚至三線支撐團隊，一線好理解，一般是7x24小時值班的同學們。
二線一般是資深工程師，或者是對應的應用開發(fā)／測試同學。
三線一般是主管或者是外部的廠家，如涉及硬件、IDC機房等相關服務方。
如果管理比較細一些，還會進行業(yè)務拆分，形成一個矩陣，例如一線、二線根據(jù)不同專業(yè)，如負責網(wǎng)絡和負責不同應用的團隊。
另外還要考慮告警嚴重的程度級別，進行差異化處理，要求嚴格的同學一般會建立響應級別[1-3]或[1-5]：
嚴重級別，如大范圍影響業(yè)務／終端用戶的，需要及時處理。一般要求多長時間響應處理，如3-10分鐘有人響應，無響應立刻升級。
警告級別：影響范圍和嚴重程度會低一些的故障，處理時長可以長一些。
提醒級別：依次更低。
那么問題來了，規(guī)劃和設計挺好，如何落地呢？目前看zabbix、nagios、open-falcon等監(jiān)控工具更多是聚焦如何發(fā)現(xiàn)問題，支撐流程屬于處理問題的范疇，或者是說管理范疇，這一點目前市面上合適工具較少：
人肉方式：一個監(jiān)控班，7x24值班，人為處理和通知。大多運營商和金融及其他超大規(guī)模公司的管理方式。
-
技術實現(xiàn)方式：通過分派策略、標簽識別、排班機制等：
通過分派策略、可以進行流程的設計，根據(jù)級別、應用設置對應的一、二線負責人，以及處理時限，超時未響應（確認告警）自動升級。
標簽技巧，如何識別不同業(yè)務和應用，一般來說可以在告警的標題打標簽，如[HOST][NETWORK]等，或者是通過zabbix／nagios的hostgroup, applications等字段打標簽。這樣在分派策略就可以進行（正則）匹配了。
排班，7x24小時緊繃狀態(tài)不是誰都能扛得住的，適當輪班緩解下壓力?？梢酝ㄟ^排班機制，白夜班，按周等模式進行輪流。
接觸過一個互聯(lián)網(wǎng)金融公司，設計了非常規(guī)范化的流程和P0-P5級別應急處理方案，涉及了網(wǎng)絡、云平臺、近50個應用研發(fā)團隊。
分派升級
排班管理
通知到位和及時響應
再好的流程和設計，當時沒有及時收到通知和處理，那么就會很郁悶了，最后一公里問題解決方式：
- 郵件通知，簡單有效，就是不夠及時。
- 短信方式，需要開發(fā)對接，目前很多公司都有自己的短信服務通道。要注意一個限制：部分運營商會限制一天相類似內容只能發(fā)送10－30條。
- 微信、移動APP通知，適應移動大潮。微信方式，好處是人人都有，壞處就是告警消息和正常溝通消息會混淆。
- 電話，救命線，電話通知可以應對特別重要的告警，例如晚上嚴重的電話通知，目前這一點國內也有不少服務商，需要對接下。
- QQ，釘釘、worktile等協(xié)作類工具，這一點屬于彩蛋性質。
還支持幾點：不同級別、不同時間段的設置，例如晚上嚴重的電話通知，白天工作時間就不用了。
這里面還存在一個問題，當告警規(guī)模大了后，特別是告警風暴的話，很容易撐爆郵箱或者是手機短信了，所以接下來就聊下告警風暴規(guī)避的問題。
告警關聯(lián)合并
這個問題比較大，基本上有些監(jiān)控工具做了一部分，目前看也是一個業(yè)界難題，簡單來說：
靜態(tài)規(guī)則方式，需要知識經(jīng)驗積累，根據(jù)業(yè)務邏輯梳理出一些父子關系。簡單如，出現(xiàn)服務器Down的告警，肯定該機器上的業(yè)務應用也會Down，那么就整理為一條規(guī)則。需要一套告警的過濾引擎，根據(jù)告警字段信息進行匹配。
關聯(lián)關系分析，依賴CMDB，服務關聯(lián)關系，根據(jù)調用依賴關系進行告警的根源追溯。CMDB的建設和維護是非常困難的事情，數(shù)據(jù)準確性和實時性是決定CMDB效果的根本因素。CMDB國內落地效果理想的很少，只能依賴自動化，微服務、docker、devops大量應用讓IT環(huán)境更動態(tài)、更復雜，沒有自動化機制保障是非常困難的。
機器學習方式，相比前兩種方式，機器學習更取巧一些，或者是說應該是未來的方向，節(jié)省大量人力物力。
我們目前做了一些嘗試分享下：
時間序列合并，如同一個告警信息，每個幾分鐘發(fā)生一次，就會合并，直到告警恢復／關閉掉。
機器學習合并，包括實時計算和離線計算，算法方面參考了相似度、決策樹、分類等算法。以相似度來說：首先采集告警的多維度信息，包括時間、主機、服務、分組hostgroups、應用applications、標簽tags等基本維度信息，計算不同告警之間相似度，如果達到閾值，如告警A和告警B有70%相似就關聯(lián)起來。目前沒有一種算法是最合適的，以相似度為例因為根據(jù)業(yè)務不同，各維度的權重，閾值靈敏度有些差異。例如某些應用的機器名規(guī)范化很高，如portal_mysql_master,portal_mysql_slave1,portal_mysql_slave2之類的，機器名權重可以高一些。機器學習領域是未來的重要發(fā)展方向，目前我們還在摸索中。
通知合并，瞬間告警通知量大的情況下，降頻合并發(fā)送通知，如有16條告警未處理。
機器學習告警合并
事件單Incident的處理
如果告警量很大，告警后續(xù)處理和跟蹤往往會依賴于外部團隊（部門外或公司外）。但是監(jiān)控告警粒度太細了，可能很多告警都是一個事情。如上面的告警風暴中，由于應用程序故障，引發(fā)引發(fā)了大量的異常，之后又產(chǎn)生連鎖反應，其實就是一個事情，只需要處理一個事情就行。
一般來說一線人員會采用郵件或者電話方式，直接通知對應負責人，但是這個就很難追蹤和事后分析，所以一套事件管理機制。
ITIL規(guī)范的事件Incident流程很有參考價值，感興趣同學參考下。事件工單需要：
將批量告警轉為事件工單，這里包括手動轉發(fā)和自動匹配規(guī)則轉發(fā)。
手動生成事件工單，一般屬于非告警類觸發(fā)，如人工發(fā)現(xiàn)或用戶投訴等引發(fā)的事件。
事件工單包括影響范圍、嚴重程度，兩者的交叉矩陣影響到處理的優(yōu)先級。包括分類、子類、自定義標簽，分類和標記有助于后續(xù)的統(tǒng)計分析。
責任人和責任組，分派到其他團隊或個人，并通知提醒。
事件單
| 影響范圍 | 緊急程度 | 優(yōu)先級 |
|---|---|---|
| 1-高 | 1-高 | 1-關鍵 |
| 1-高 | 2-中 | 2-重要 |
| 1-高 | 3-低 | 3-普通 |
| 2-中 | 1-高 | 2-重要 |
| 2-中 | 2-中 | 3-普通 |
| 2-中 | 3-低 | 4-次要 |
| 3-低 | 1-高 | 3-普通 |
| 3-低 | 2-中 | 4-次要 |
| 3-低 | 3-低 | 5-待定 |
影響范圍和緊急程度的交叉矩陣影響到優(yōu)先級
小結
On-Call機制建立后，通過告警和事件數(shù)據(jù)分析、建立起以數(shù)據(jù)指標驅動的團隊文化，有機會和大家分享。
OneAlert 是 OneAPM 旗下產(chǎn)品，是國內第一個 SaaS 模式的云告警平臺，集成國內外主流監(jiān)控/支撐系統(tǒng)，實現(xiàn)一個平臺上集中處理所有 IT 事件，提升 IT 可靠性。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。
本文轉自 OneAPM 官方博客
