【摘要】 運(yùn)維累都是有原因的，此時(shí)就可以輪到故障自愈出場(chǎng)了。

【作者】 社區(qū)ID： 木訥大叔愛運(yùn)維 ，互聯(lián)網(wǎng)+金融行業(yè)，專注于運(yùn)維、數(shù)據(jù)庫(kù)領(lǐng)域，持續(xù)分享基于運(yùn)維自動(dòng)化的思考、實(shí)踐及解決方案。

背景

最近晚上23:00甚至是凌晨總收到告警通知：磁盤可用量低于20%，這個(gè)時(shí)候不得不爬起來(lái)處理告警。當(dāng)然這里要提醒大家：對(duì)于小問(wèn)題，運(yùn)維也絕不要抱著僥幸的心理，因?yàn)橹挥型催^(guò)才知道。

磁盤類告警只是我們諸多告警中的冰山一角，雖然我們有值班人員甚至是運(yùn)維團(tuán)隊(duì)支撐，但是也不能因?yàn)檫@種小問(wèn)題就分散注意力，這時(shí)我們就需要考慮如何通過(guò)自動(dòng)化實(shí)現(xiàn)。

針對(duì)這種情況，我們通常會(huì)想到以下幾點(diǎn)：

? 在告警機(jī)器上設(shè)置定時(shí)任務(wù)；

? 編寫腳本壓縮日志或清理磁盤空間。

這種方案雖然可行，但是試想下：如果我們管理的是上千臺(tái)機(jī)器且目錄結(jié)構(gòu)混亂，那么我們面臨的將是上千個(gè)腳本及定時(shí)任務(wù)，這個(gè)工作量是非常大的。

故障自愈

如圖所示，對(duì)于生產(chǎn)故障，運(yùn)維標(biāo)準(zhǔn)的處理流程是收到告警、登錄跳板機(jī)、故障處理、故障恢復(fù)，整個(gè)過(guò)程都是通過(guò)人工手動(dòng)處理。而故障自愈則是接受監(jiān)控平臺(tái)的告警定位，匹配預(yù)設(shè)的故障處理流程，進(jìn)而通過(guò)自動(dòng)化手段實(shí)現(xiàn)故障的自動(dòng)恢復(fù)。

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

1.前提

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

● 目錄管理規(guī)范標(biāo)準(zhǔn)的目錄結(jié)構(gòu)，接入故障自愈后可以用一套自動(dòng)化腳本管理所有文件資源；

● 應(yīng)用標(biāo)準(zhǔn)規(guī)范標(biāo)準(zhǔn)應(yīng)用規(guī)范，接入故障自愈后可以用一套自動(dòng)化腳本管理所有應(yīng)用；

● 監(jiān)控告警規(guī)范標(biāo)準(zhǔn)的監(jiān)控告警規(guī)范，通過(guò)告警通知，無(wú)論是運(yùn)維團(tuán)隊(duì)或自愈平臺(tái)，都能通過(guò)告警通知更快速的定位問(wèn)題；

● 標(biāo)準(zhǔn)的故障處理流程標(biāo)準(zhǔn)的故障處理流程，不僅可以幫助我們更快速的解決問(wèn)題，而且可以幫助我們建立起運(yùn)維團(tuán)隊(duì)的知識(shí)庫(kù)。

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

2.監(jiān)控平臺(tái)

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

● 硬件監(jiān)控維度此類監(jiān)控故障自愈一般無(wú)法接入，僅作為輔助手段幫我們及時(shí)發(fā)現(xiàn)問(wèn)題；

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

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

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

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

3.故障自愈平臺(tái)

（1）多告警源

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

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

● Zabbix

● Nagios

● Open Falcon

● Prometheus

● 等等

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

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

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

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

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

● 運(yùn)維團(tuán)隊(duì)內(nèi)部的認(rèn)可

● 按部門、角色對(duì)基礎(chǔ)設(shè)施的職責(zé)劃分

● CMDB的管理規(guī)范

● CMDB如何按組織架構(gòu)對(duì)環(huán)境、部門、業(yè)務(wù)、應(yīng)用等情況劃分

● 如何更合適的納管物理機(jī)、虛擬機(jī)、網(wǎng)絡(luò)設(shè)備、數(shù)據(jù)庫(kù)、中間件等資源

● CMDB如何為架構(gòu)提供數(shù)據(jù)支撐

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

（3）故障處理

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

● Ansible、SaltStack等自動(dòng)化運(yùn)維工具

● 中控機(jī)通過(guò)ssh遠(yuǎn)程執(zhí)行命令

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

● Jenkins流水線參數(shù)化構(gòu)建

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

（4）結(jié)果通知

無(wú)論最終的故障處理是否成功，我們都需要知道結(jié)果來(lái)決定是否要人工干預(yù)，因此我們希望處理結(jié)果能夠?qū)佣喾N渠道通知，如：

● 郵件通知

● 微信通知

● 釘釘通知

● 短信通知

● 電話通知

總結(jié)

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

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

是的，“羅馬不是一天建成的”，當(dāng)你看到此文時(shí)我已經(jīng)經(jīng)歷了整個(gè)運(yùn)維體系從無(wú)到有的建設(shè)過(guò)程，這些都是寶貴的財(cái)富，遂以文章將經(jīng)歷過(guò)的點(diǎn)滴記錄下來(lái)。

運(yùn)維故障治愈在企業(yè)應(yīng)用探索實(shí)踐經(jīng)驗(yàn)

點(diǎn)擊閱讀原文可到社區(qū)原文下留言交流

覺得本文有用，請(qǐng) 轉(zhuǎn)發(fā)、點(diǎn)贊 或點(diǎn)擊 賞 ，讓更多同行看到

*本公眾號(hào)所發(fā)布內(nèi)容僅代表作者觀點(diǎn)，不代表社區(qū)立場(chǎng) ； 封面圖片由版權(quán)圖庫(kù)授權(quán)使用