知識星球
以產品設計理念剖析企業建設故障自動化處理方案的思路
人工處理告警，一直是運維心中的痛。大年初一拜年、結婚、和老婆孩子外出過週末等美好時光，作為運維的你，好像一直心繫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大行其道的時候，我們需要剋制，優先解決主要矛盾，而不是構建高大上的空中樓閣。
如同產品路線圖，優先解決可用性，接下來是體驗，最後才是可擴充套件性和生態，依次落地。
（產品需求模型 by 騰訊8分鐘產品課）
最後，希望廣大的運維兄弟姐妹能儘早脫離原始運維的苦海，抓住行業發展趨勢，掌握核心技術，在變革中實現自身價值！
【你可能比較感興趣】
如果想借鑒文中的產品，請訪問http://bk.tencent.com/s-mart/application/128/detail （交流QQ群：495299374）
《Linux雲端計算及運維架構師高薪實戰班》2018年05月14日即將開課中，120天衝擊Linux運維年薪30萬，改變速約~~~~
*宣告：推送內容及圖片來源於網路，部分內容會有所改動，版權歸原作者所有，如來源資訊有誤或侵犯權益，請聯絡我們刪除或授權事宜。
– END –
