有效運維的 on-call 機制

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

正文

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

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

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

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

1. 監控告警事件集中化。

2. 創建多層次和職責劃分的支撐團隊。

3. 通知到位和及時響應。

4. 告警風暴關聯合並。

5. 事件單記錄和團隊協做。

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

監控告警集中化

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

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

2. 若是有多個異地數據中心時，可能須要部署多個zabbix和工具。

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

告警集中化，就是全部的生產監控發現的告警事件集中到一塊兒，這樣咱們盯着一個平臺就夠了，一樣也容易分析問題，是否是相同和相似緣由。

1. 可以直觀掌握現有環境的情況。

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

3. 方便跟蹤和後續的統計分析。

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

創建支撐流程和機制

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

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

• 二線通常是資深工程師，或者是對應的應用開發／測試同窗。

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

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

• 嚴重級別，如大範圍影響業務／終端用戶的，須要及時處理。通常要求多長時間響應處理，如3-10分鐘有人響應，無響應馬上升級。

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

• 提醒級別：依次更低。

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

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

2. 技術實現方式：經過分派策略、標籤識別、排班機制等：

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

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

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

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

分派升級

排班管理

通知到位和及時響應

再好的流程和設計，當時沒有及時收到通知和處理，那麼就會很鬱悶了，最後一千米問題解決方式：

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

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

告警關聯合並

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

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

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

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

咱們目前作了一些嘗試分享下：

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

• 機器學習合併，包括實時計算和離線計算，算法方面參考了類似度、決策樹、分類等算法。以類似度來講：首先採集告警的多維度信息，包括時間、主機、服務、分組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 官方博客