歡迎光臨
每天分享高質量文章

故障自愈:解決運維的主要矛盾才能AIOps

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

人工處理告警,一直是運維心中的痛。大年初一拜年、結婚、和老婆孩子外出過周末等美好時光,作為運維的你,好像一直心系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 –


    赞(0)

    分享創造快樂