以產品設計理念剖析企業建設故障自動化處理方案的思路

人工處理告警，一直是運維心中的痛。大年初一拜年、結婚、和老婆孩子外出過周末等美好時光，作為運維的你，好像一直心系IT系統，保持與筆記本的安全距離。

為什么這么多年過去了，還是這么苦逼，不是說運維行業轉 AIOps了，我竟然還在手工處理告警，我該怎么辦？

今天就和大家聊聊實現故障自愈要攻克的3個問題，以及獻上開箱即用的方案。

1. 故障自愈的基本流程

自動化的要點是什么？把人的經驗抽象、固化為程序處理，工業（第3次工業革命）或互聯網都是如此。

舉個例子，磁盤出現告警，運維首先想到的是登陸服務器清理磁盤。

（人工處理告警的流程）

接下來，我們拆解背后的邏輯。

1.1 抽象告警處理流程

1)拉取磁盤告警

2) 編寫磁盤清理的腳本或作業任務

3) 設計模塊：把拉取到的磁盤告警，與調用腳本的模塊串起來

（故障自愈流程 簡化版V1）

1.2 通過CMDB做資源清洗

不同模塊的磁盤清理方案不一樣，如何解決呢？

這時需要引入CMDB（設備、人、業務的映射關系），通過CMDB把IP清洗為模塊，這樣就解決了接入層 和 邏輯層、存儲層的告警使用對應的磁盤清理方案。

（故障自愈流程 簡化版V2）

1.3 對接企業內部網關

故障自愈可能會處理失敗，這時需要通知用戶。故障自愈的處理方式除了調用作業外，還可能需要調用企業內部的網關，比如服務器重啟、申請服務器等。

使用PaaS層的ESB是一種解決思路，通過ESB封裝企業內部網關，解決權限校驗、頻率控制、訪問統計、路由分發以及自助接入等功能，不要直接調用裸接口了。

（故障自愈的通知方案）

經過這一輪的探索，故障自愈的架構就是下面這個樣子。

（故障自愈的流程）

1.4 對接企業內部監控產品

等等，好像還沒說如何對接企業內部的監控產品，以Zabbix、Open-Falcon為例。

1.4.1 對接Zabbix

《當Zabbix遇見故障自愈》介紹了拉取Zabbix告警的方案，通過 ActionScript 調用腳本，把 Zabbix 告警推送至自愈的告警拉取模塊。

推送（或叫回調）可以保證告警拉取的實時性。

（Zabbix推送告警示例）

（Zabbix調用推送告警的腳本）

對接Zabbix 的落地案例可以參考陳亮撰寫的那些年我們想做的無人值守。

除Zabbix外，Open-Falcon在國內的社區熱度也不錯，所以也介紹拉取其告警的方案。

1.4.2 對接Open-falcon

方案類似Zabbix，不過Open-falcon 直接提供了callback功能，簡化了流程。

(Open-Falcon配置Callback地址)

收到了Open-Falcon 推送的告警后，解析對應的字段即可。

如果企業內部的CMDB以IP來標識主機，需要再做一層轉換，因為Open-Falcon 的資源標識endpoint默認是主機名，那么就需要使用CMDB的自動發現功能自動上報主機名，同時提供把主機名清洗為IP的功能。

下面是Nginx模塊磁盤告警的自愈示例，匹配Nginx模塊的磁盤清理套餐，清理Nginx模塊的日志文件，整個過程不到30秒。

（磁盤告警的自愈示例）

2. 故障自愈的兩面性

故障自動處理就像一把刀，有其兩面性。

因為要確保告警的真實性，一旦把假告警也自動處理了，就很悲催了…

舉個例子。網絡波動，批量出現PING告警。實際上服務器運行正常，這時你把服務器都重啟了，那就GG了。

如何解決呢？分析事物的規律。

批量出現告警，那可以在告警拉取模塊后面，增加一個收斂模塊。

比如，在X時間內出現Y個告警，打電話給運維審批。

X時間內同一主機出現使用相同套餐的告警，則收斂時間窗口中后面的告警則跳過，比如同時收到進程告警 和 端口告警，就不用拉2次進程了。

還有就是，原有監控系統沒有收斂能力，那么可以借用這個功能來做告警匯總，因為收斂邏輯一樣，只是收斂的處理方式有差異。

3. 復雜告警的處理方案 - 組合套餐

上面提到的技術方案是用來處理邏輯簡單的告警，那么故障替換這種復雜的場景如何解決呢？

舉個例子，A模塊是重要模塊，出現PING不可達告警，首先要校驗A模塊是否真的故障，如果真的故障，接下來是從資源池中獲取備機 … 故障替換等等，期間每個環節都有可能出錯，那就要考慮異常分支的場景。

樹結構可以解決該問題，二叉樹足以滿足大部分場景（成功、失敗兩種分支）。

( 組合套餐的示例)

上面這張圖，是一個自愈處理方案，可以稱之為組合套餐。

這里同時引入了原子的概念，通過組裝原子來滿足各種需求場景， 和資源編排說的是同一個理兒。

注：如果你想使用三叉樹，其實可以把組合套餐也作為一個原子套餐（節點）。

4. 故障自愈的技術架構

經過前面對故障自愈的基本流程、故障自愈的兩面性、復雜的故障處理方案的層層梳理，我們有了一張故障自愈的技術架構圖。

相信這次以經行業驗證的故障自愈做技術剖析，能對大家建設企業內部的故障自動處理方案提供參考思路。

5. 收尾

當 AIOps大行其道的時候，我們需要克制，優先解決主要矛盾，而不是構建高大上的空中樓閣。

如同產品路線圖，優先解決可用性，接下來是體驗，最后才是可擴展性和生態，依次落地。

最后，希望廣大的運維兄弟姐妹能盡早脫離原始運維的苦海，抓住行業發展趨勢，掌握核心技術，在變革中實現自身價值！