網際網路技術的發展，離不開運維支撐工作，沒有零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等，或者是通過zabbix／nagios的hostgroup, applications等字段打标簽。這樣在分派政策就可以進行（正則）比對了。
排班，7x24小時緊繃狀态不是誰都能扛得住的，适當輪班緩解下壓力。可以通過排班機制，白夜班，按周等模式進行輪流。
接觸過一個網際網路金融公司，設計了非正常範化的流程和p0-p5級别應急處理方案，涉及了網絡、雲平台、近50個應用研發團隊。
分派更新
排班管理
再好的流程和設計，當時沒有及時收到通知和處理，那麼就會很郁悶了，最後一公裡問題解決方式：
郵件通知，簡單有效，就是不夠及時。
短信方式，需要開發對接，目前很多公司都有自己的短信服務通道。要注意一個限制：部分營運商會限制一天相類似内容隻能發送10－30條。
微信、移動app通知，适應移動大潮。微信方式，好處是人人都有，壞處就是告警消息和正常溝通消息會混淆。
電話，救命線，電話通知可以應對特别重要的告警，例如晚上嚴重的電話通知，目前這一點國内也有不少服務商，需要對接下。
qq，釘釘、worktile等協作類工具，這一點屬于彩蛋性質。
還支援幾點：不同級别、不同時間段的設定，例如晚上嚴重的電話通知，白天工作時間就不用了。
這裡面還存在一個問題，當告警規模大了後，特别是告警風暴的話，很容易撐爆郵箱或者是手機短信了，是以接下來就聊下告警風暴規避的問題。
這個問題比較大，基本上有些監控工具做了一部分，目前看也是一個業界難題，簡單來說：
靜态規則方式，需要知識經驗積累，根據業務邏輯梳理出一些父子關系。簡單如，出現伺服器down的告警，肯定該機器上的業務應用也會down，那麼就整理為一條規則。需要一套告警的過濾引擎，根據告警字段資訊進行比對。
關聯關系分析，依賴cmdb，服務關聯關系，根據調用依賴關系進行告警的根源追溯。cmdb的建設和維護是非常困難的事情，資料準确性和實時性是決定cmdb效果的根本因素。cmdb國内落地效果理想的很少，隻能依賴自動化，微服務、docker、devops大量應用讓it環境更動态、更複雜，沒有自動化機制保障是非常困難的。
機器學習方式，相比前兩種方式，機器學習更取巧一些，或者是說應該是未來的方向，節省大量人力物力。
我們目前做了一些嘗試分享下：
時間序列合并，如同一個告警資訊，每個幾分鐘發生一次，就會合并，直到告警恢複／關閉掉。
通知合并，瞬間告警通知量大的情況下，降頻合并發送通知，如有16條告警未處理。
機器學習告警合并
如果告警量很大，告警後續處理和跟蹤往往會依賴于外部團隊（部門外或公司外）。但是監控告警粒度太細了，可能很多告警都是一個事情。如上面的告警風暴中，由于應用程式故障，引發引發了大量的異常，之後又産生連鎖反應，其實就是一個事情，隻需要處理一個事情就行。
一般來說一線人員會采用郵件或者電話方式，直接通知對應負責人，但是這個就很難追蹤和事後分析，是以一套事件管理機制。
itil規範的事件incident流程很有參考價值，感興趣同學參考下。事件工單需要：
将批量告警轉為事件工單，這裡包括手動轉發和自動比對規則轉發。
手動生成事件工單，一般屬于非告警類觸發，如人工發現或使用者投訴等引發的事件。
事件工單包括影響範圍、嚴重程度，兩者的交叉矩陣影響到處理的優先級。包括分類、子類、自定義标簽，分類和标記有助于後續的統計分析。
責任人和責任組，分派到其他團隊或個人，并通知提醒。
事件單
影響範圍
緊急程度
優先級
1-高
1-關鍵
2-中
2-重要
3-低
3-普通
4-次要
5-待定
影響範圍和緊急程度的交叉矩陣影響到優先級
on-call機制建立後，通過告警和事件資料分析、建立起以資料名額驅動的團隊文化，有機會和大家分享。