互聯網技術的發展離不開運維支撐，沒有不出bug的程序，也沒有不出問題的系統，出現問題故障並不可怕。可怕的是無法有序處理:
如何有效地處理緊急驅動的工作已成為運維的關鍵（尤其是對運維主管而言）。我接觸過大量公司的運維。從初創公司、中小公司和大公司，我總結和分享了壹些大多數公司常用的隨叫隨到機制，以幫助有序地處理緊急情況:
基本上，它是圍繞人、流程和工具進行的，參考了ITIL的管理思想。有興趣也可以參考壹下，尤其是ITIL V3的運營管理。
大多數公司使用zabbix、nagios和open-falcon等監控工具來監控硬件、網絡和應用程序。可能存在分散監控的問題:
報警集中是指生產監控中發現的所有報警事件都集中在壹起，這樣我們盯著壹個平臺就足夠了，也很容易分析問題，是否相同或相似。
如果監控工具單壹，集中化不是最必要的，但如何有序應對才是核心。專項運維團隊3-5人到幾十/上百人，需要梳理支持流程和響應機制。
如果管理更細致，業務將被拆分以形成矩陣。例如，壹線和二線基於不同的專業，例如負責網絡和不同應用程序的團隊。
此外，應考慮和區分警報的嚴重級別。要求嚴格的學生壹般會建立壹個響應級別【1-3】或【1-5】:
那麽問題來了，規劃設計都挺好的，怎麽落地呢？目前，zabbix、nagios和open-falcon等監控工具更側重於如何發現問題，而支持過程屬於處理問題的範疇，或管理。目前，市場上幾乎沒有合適的工具:
我聯系了壹家互聯網金融公司，設計了非常標準化的流程和P0-P5應急處理方案，涉及網絡、雲平臺和近50個應用R&D團隊。
任務升級
調度管理
無論工藝和設計有多好，如果我們沒有收到通知並及時處理，我們都會非常沮喪。最後壹英裏問題的解決方案是:
它還支持以下幾點:白天工作時間不需要不同級別和不同時間段的設置，例如晚上嚴肅的電話通知。
這仍然有壹個問題。當報警規模較大時，尤其是報警風暴時，很容易導致郵箱或手機短信爆倉，所以我們來談談避免報警風暴的問題。
這個問題比較大，基本上壹些監控工具做了壹部分，目前也是行業問題。簡單地說:
我們嘗試分享以下內容:
機器學習警報合並
如果有大量告警，告警的後續處理和跟蹤往往依賴於外部團隊（外部部門或公司）。但是監控告警的粒度太細，很多告警可能是壹件事。例如，在上面的警報風暴中，由於應用程序故障而觸發了大量異常，然後發生了連鎖反應。事實上，它只是壹件事，只有壹件事需要處理。
壹般來說，壹線人員會通過電子郵件或電話直接通知相應的負責人，但這很難進行事後跟蹤和分析，因此設置了事件管理機制。
ITIL標準事件過程很有參考價值，感興趣的同學可以參考壹下。事件工作單要求:
事件表
影響範圍和緊急程度的交叉矩陣影響優先級。
隨叫隨到機制建立後，通過對告警和事件數據的分析，建立了以數據指標驅動的團隊文化，我有機會分享給大家。
OneA lert是OneAPM的產品，是中國第壹個基於SaaS的雲報警平臺，它集成了國內外主流的監控/支持系統，以實現在壹個平臺上集中處理所有IT事件並提高IT可靠性。要閱讀更多技術文章，請訪問OneAPM的官方技術博客。
本文轉自OneAPM官博。