一、背景

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

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

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

• 在告警機(jī)器上設(shè)置定時(shí)任務(wù)
• 編寫(xiě)腳本壓縮日志或清理磁盤(pán)空間?

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

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

二、故障自愈

如圖所示，對(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ī)器或某一類(lèi)故障。因此在正式接入故障自愈前，我們還有很多的工作要做。

三、前提

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

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

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

2）應(yīng)用標(biāo)準(zhǔn)規(guī)范

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

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

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

4）標(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ǔ)性的工作是多么的重要。

四、監(jiān)控平臺(tái)

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

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

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

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

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

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

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

4）中間件維度

中間件維度主要是對(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ì)不斷豐富。

五、故障自愈平臺(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)滿(mǎn)足運(yùn)維監(jiān)控需求。

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

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

當(dāng)然除了滿(mǎn)足與監(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)可
• 按部門(mén)、角色對(duì)基礎(chǔ)設(shè)施的職責(zé)劃分
• CMDB的管理規(guī)范
• CMDB如何按組織架構(gòu)對(duì)環(huán)境、部門(mén)、業(yè)務(wù)、應(yīng)用等情況劃分
• 如何更合適的納管物理機(jī)、虛擬機(jī)、網(wǎng)絡(luò)設(shè)備、數(shù)據(jù)庫(kù)、中間件等資源
• CMDB如何為架構(gòu)提供數(shù)據(jù)支撐

以上這些問(wèn)題也只是在使用推廣階段我們所遇到的，因此在很多情況下CMDB都從萬(wàn)眾期待走向了置之不理，但“撥開(kāi)云霧見(jiàn)天日，守得云開(kāi)見(jià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)雅的方式供我們參考：

• 集成CMDB的統(tǒng)一作業(yè)平臺(tái)
• 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í)踐摸索。