[編者按]本文作者為云告警平臺OneAlert負責人，著《云計算與OpenStack》，在IT運營管理、云計算方面從業10多年。

正文

互聯網技術的發展，離不開運維支撐工作，沒有零bug的程序，沒有不出問題的系統，問題故障不可怕，可怕的是沒能有序的處理：

突發緊急事件太多，疲于應付，團隊士氣低下，效率不高。

重要事情淹沒在大量事件中，沒有有序跟進處理，會引發嚴重業務影響。

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

監控告警事件集中化。

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

通知到位和及時響應。

告警風暴關聯合并。

事件單記錄和團隊協作。

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

監控告警集中化

大多公司都用了zabbix和nagios、open-falcon等監控工具，對硬件、網絡、應用進行監控。可能會存在監控分散問題：

環境比較復雜的時候，可能會用多個工具，如cacti監控網絡，zabbix監控應用和服務器。

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

部分關鍵業務，需要單獨的開發監控腳本／工具進行獨立監測。
如果沒有集中告警機制，容易出現郵件滿天飛的現象，也很難跟進和處理，郵件也容易遺漏。

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

能夠直觀掌握現有環境的狀況。

發現事件相關性的，有些問題有較強關聯性的，如網絡穩定性影響主機，數據庫性能影響業務等。

方便跟蹤和后續的統計分析。

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

建立支撐流程和機制

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

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

• 二線一般是資深工程師，或者是對應的應用開發／測試同學。

• 三線一般是主管或者是外部的廠家，如涉及硬件、IDC機房等相關服務方。

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

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

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

• 提醒級別：依次更低。

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

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

技術實現方式：通過分派策略、標簽識別、排班機制等：

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

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

• 排班，7x24小時緊繃狀態不是誰都能扛得住的，適當輪班緩解下壓力。可以通過排班機制，白夜班，按周等模式進行輪流。

接觸過一個互聯網金融公司，設計了非常規范化的流程和P0-P5級別應急處理方案，涉及了網絡、云平臺、近50個應用研發團隊。

分派升級

排班管理

通知到位和及時響應

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

• 郵件通知，簡單有效，就是不夠及時。
• 短信方式，需要開發對接，目前很多公司都有自己的短信服務通道。要注意一個限制：部分運營商會限制一天相類似內容只能發送10－30條。
• 微信、移動APP通知，適應移動大潮。微信方式，好處是人人都有，壞處就是告警消息和正常溝通消息會混淆。
• 電話，救命線，電話通知可以應對特別重要的告警，例如晚上嚴重的電話通知，目前這一點國內也有不少服務商，需要對接下。
• QQ，釘釘、worktile等協作類工具，這一點屬于彩蛋性質。

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

告警關聯合并

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

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

關聯關系分析，依賴CMDB，服務關聯關系，根據調用依賴關系進行告警的根源追溯。CMDB的建設和維護是非常困難的事情，數據準確性和實時性是決定CMDB效果的根本因素。CMDB國內落地效果理想的很少，只能依賴自動化，微服務、docker、devops大量應用讓IT環境更動態、更復雜，沒有自動化機制保障是非常困難的。

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

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

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

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

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

機器學習告警合并

事件單Incident的處理

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

• 將批量告警轉為事件工單，這里包括手動轉發和自動匹配規則轉發。

• 手動生成事件工單，一般屬于非告警類觸發，如人工發現或用戶投訴等引發的事件。

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

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

事件單

影響范圍緊急程度優先級

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-待定

影響范圍和緊急程度的交叉矩陣影響到優先級

小結

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

OneAlert 是 OneAPM 旗下產品，是國內第一個 SaaS 模式的云告警平臺，集成國內外主流監控/支撐系統，實現一個平臺上集中處理所有 IT 事件，提升 IT 可靠性。想技術文章，請訪問 OneAPM 官方技術博客。

本文轉自 OneAPM 官方博客

轉載于:https://www.cnblogs.com/oneapm/p/5600676.html

總結

以上是生活随笔為你收集整理的有效运维的 on-call 机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。