一、背景

最近晚上23:00甚至是凌晨總收到告警通知：磁盤可用量低于20%，這個時候不得不爬起來處理告警。當然這里要提醒大家：對于小問題，運維也絕不要抱著僥幸的心理，因為只有痛過才知道。

磁盤類告警只是我們諸多告警中的冰山一角，雖然我們有值班人員甚至是運維團隊支撐，但是也不能因為這種小問題就分散注意力，這時我們就需要考慮如何通過自動化實現(xiàn)。

針對這種情況，我們通常會想到以下幾點：

• 在告警機器上設置定時任務
• 編寫腳本壓縮日志或清理磁盤空間?

這種方案雖然可行，但是試想下：如果我們管理的是上千臺機器且目錄結構混亂，那么我們面臨的將是上千個腳本及定時任務，這個工作量是非常大的。

運維累都是有原因的，此時就可以輪到故障自愈出場了。

二、故障自愈

如圖所示，對于生產(chǎn)故障，運維標準的處理流程是收到告警、登錄跳板機、故障處理、故障恢復，整個過程都是通過人工手動處理。而故障自愈則是接受監(jiān)控平臺的告警定位，匹配預設的故障處理流程，進而通過自動化手段實現(xiàn)故障的自動恢復。

在認識故障自愈后，我們需要考慮的就是如何讓運維管理的生產(chǎn)環(huán)境更廣泛地接入故障自愈，而不是只針對單一的機器或某一類故障。因此在正式接入故障自愈前，我們還有很多的工作要做。

三、前提

為滿足故障自愈通過自動化手段處理故障，我們必須提前制定一系列的流程規(guī)范：

1）目錄管理規(guī)范

標準的目錄結構，接入故障自愈后可以用一套自動化腳本管理所有文件資源。

2）應用標準規(guī)范

標準應用規(guī)范，接入故障自愈后可以用一套自動化腳本管理所有應用。

3）監(jiān)控告警規(guī)范

標準的監(jiān)控告警規(guī)范，通過告警通知，無論是運維團隊或自愈平臺，都能通過告警通知更快速的定位問題。

4）標準的故障處理流程

標準的故障處理流程，不僅可以幫助我們更快速地解決問題，而且可以幫助我們建立起運維團隊的知識庫。

這些流程規(guī)范不僅是故障自愈，也是我們?nèi)粘＿\維工作過程中需要持續(xù)關注的，這也意味著這些基礎性的工作是多么的重要。

四、監(jiān)控平臺

監(jiān)控平臺作為整個故障自愈的源頭，必須滿足快速準確定位故障的要求，因此就需要在多個維度提供可靠的監(jiān)控。

1）硬件監(jiān)控維度

此類監(jiān)控故障自愈一般無法接入，僅作為輔助手段幫我們及時發(fā)現(xiàn)問題。

2）基礎監(jiān)控維度

基礎監(jiān)控主要是對CPU、內(nèi)存、磁盤等資源使用情況進行監(jiān)控，接入故障自愈后可發(fā)送占用資源的top10進程及自定義的磁盤清理策略。

3）應用監(jiān)控維度

應用監(jiān)控主要是對應用狀態(tài)進行監(jiān)控，如健康檢查、端口、其他自定義告警，接入故障自愈后可對應用進行重啟。

4）中間件維度

中間件維度主要是對集群的健康狀態(tài)進行監(jiān)控，如eureka instance、rabbitmq集群各節(jié)點服務、redis集群各節(jié)點服務等，接入故障自愈后可對各節(jié)點的服務進行處理。

當然根據(jù)監(jiān)控平臺的維度和粒度，我們可以將更多的故障場景接入故障自愈，這個隨著我們運維經(jīng)驗的增多會不斷豐富。

五、故障自愈平臺

1、多告警源

故障自愈的源頭是監(jiān)控平臺，因此我們希望故障自愈平臺不能是只針對某一特定的監(jiān)控平臺，因此它一定是多源的，這也符合當今監(jiān)控工具的發(fā)展趨勢。新的業(yè)務、系統(tǒng)和場景會催生新的監(jiān)控需求，企業(yè)未來監(jiān)控一定是多種監(jiān)控產(chǎn)品并存，構建功能可持續(xù)成長的監(jiān)控平臺才能適應滿足運維監(jiān)控需求。

當今主流的監(jiān)控工具如下：

• Zabbix
• Nagios
• Open Falcon
• Prometheus
• 等等

當然除了滿足與監(jiān)控工具對接，還要兼具REST API等方式接入。

2、統(tǒng)一數(shù)據(jù)源

試想一個場景，通過監(jiān)控平臺發(fā)送的告警通知，我們可以快速定位到業(yè)務、應用、IP，那么故障自愈平臺如何接入這些資源呢？因此我們就需要一個統(tǒng)一的數(shù)據(jù)源，為監(jiān)控平臺、故障自愈平臺等上層應用提供可靠的權威數(shù)據(jù)源，此時CMDB就可以擔任如此重要的角色。

在 ITIL 體系里，CMDB 是構建其它流程的基石，為應用提供了各種運維場景的配置數(shù)據(jù)服務。它是企業(yè) IT 管理體系的核心，通過提供配置管理服務，以數(shù)據(jù)和模型相結合映射應用間的關系，保證數(shù)據(jù)的準確和一致性；并以整合的思路推進，最終面向應用消費，發(fā)揮配置服務的價值。

CMDB的建設是一個非常痛苦的過程，雖然我們是站在巨人的肩膀上直接使用其能力進行納管資源，但其實也是走了很多彎路的：

• 運維團隊內(nèi)部的認可
• 按部門、角色對基礎設施的職責劃分
• CMDB的管理規(guī)范
• CMDB如何按組織架構對環(huán)境、部門、業(yè)務、應用等情況劃分
• 如何更合適的納管物理機、虛擬機、網(wǎng)絡設備、數(shù)據(jù)庫、中間件等資源
• CMDB如何為架構提供數(shù)據(jù)支撐

以上這些問題也只是在使用推廣階段我們所遇到的，因此在很多情況下CMDB都從萬眾期待走向了置之不理，但“撥開云霧見天日，守得云開見月明”，隨著我們不遺余力的嘗試與調(diào)整，CMDB 最終還是扛下了所有，發(fā)揮了它真正的價值。

3、故障處理

有了統(tǒng)一的數(shù)據(jù)源，剩下的操作就是如何進行故障處理了，此時就需求故障自愈平臺能夠遠程執(zhí)行腳本。在日常運維工作中，我們一般通過以下幾種方式：

• Ansible、SaltStack等自動化運維工具
• 中控機通過ssh遠程執(zhí)行命令

以上是我們通常使用的手段，但是還有更高級或更優(yōu)雅的方式供我們參考：

• 集成CMDB的統(tǒng)一作業(yè)平臺
• Jenkins流水線參數(shù)化構建

當然了，“不管黑貓白貓，能捉老鼠的就是好貓”，只要是適合當下運維能力的任何方式都可以。不要一味地追求高大上，給我們帶來其他額外的工作負擔。

4、結果通知

無論最終的故障處理是否成功，我們都需要知道結果來決定是否要人工干預，因此我們希望處理結果能夠對接多種渠道通知，如：

• 郵件通知
• 微信通知
• 釘釘通知
• 短信通知
• 電話通知
• 等等

六、總結

從上圖我們可以看到，故障自愈雖然可以幫助我們解決很多問題，但其也只是問題處理過程中的一個環(huán)節(jié)，例如例行維護期間我們需要做到不觸發(fā)故障自愈，否則還可能引起一些不必要的問題。因此，故障自愈還需和其他組件做好密切的對接，這就通過運維管理人員進行調(diào)度了。

最后需要明確的是，故障自愈只是運維過程中的一種手段而已，如何將其更廣泛的應用還需運維本身去腳踏實地地去實踐摸索。