一、背景

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

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

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

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

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

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

二、故障自愈

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

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

三、前提

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

1）目錄管理規范

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

2）應用標準規范

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

3）監控告警規范

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

4）標準的故障處理流程

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

這些流程規范不僅是故障自愈，也是我們日常運維工作過程中需要持續關注的，這也意味著這些基礎性的工作是多么的重要。

四、監控平臺

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

1）硬件監控維度

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

2）基礎監控維度

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

3）應用監控維度

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

4）中間件維度

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

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

五、故障自愈平臺

1、多告警源

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

當今主流的監控工具如下：

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

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

2、統一數據源

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

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

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

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

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

3、故障處理

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

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

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

• 集成CMDB的統一作業平臺
• Jenkins流水線參數化構建

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

4、結果通知

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

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

六、總結

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

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