從故障自愈看穩(wěn)定性保障體系
點(diǎn)擊上方“IT那活兒”公眾號(hào)，關(guān)注后了解更多內(nèi)容，不管IT什么活兒，干就完了?。?！
故障自愈是指實(shí)時(shí)發(fā)現(xiàn)告警，預(yù)診斷分析，自動(dòng)恢復(fù)故障，并打通周邊系統(tǒng)實(shí)現(xiàn)故障的快速恢復(fù)。故障自愈在是穩(wěn)定性保障能力中是重要的一環(huán)，在穩(wěn)定性保障體系中主要是通過自動(dòng)化、半自動(dòng)化的手段對(duì)執(zhí)行故障預(yù)案對(duì)故障修復(fù)，提升MTTR，并通過故障復(fù)盤來降低MTTF。今天筆者想從故障自愈的角度入手去聊下故障的處理流程，這里包含簡單的處理預(yù)案的告警自愈，有告警快照獲取并進(jìn)行自動(dòng)化自愈的故障自愈，也有站在整個(gè)故障的角度對(duì)故障進(jìn)行協(xié)同處理的故障處理流程。故障自愈主要是分為兩種：一種是消極的故障自愈，另一個(gè)是積極的故障自愈。本文可能涉及到一些協(xié)作平臺(tái)的介紹，當(dāng)然這里的協(xié)作都是指的運(yùn)維協(xié)作。
隨著各領(lǐng)域數(shù)字化轉(zhuǎn)型的推進(jìn)，信息系統(tǒng)的應(yīng)用范圍不斷擴(kuò)大、 承載業(yè)務(wù)愈發(fā)關(guān)鍵，用戶的高頻訪問成為常態(tài)。面對(duì)業(yè)務(wù)的需求，IT技術(shù)也在不斷的演進(jìn)，IT開始走向分布式，而近幾年分布式其實(shí)發(fā)生了很多的變化，從最早的10年11年的時(shí)候，可能大家熟悉的SOA甚至在之前EJB，然后到后來的這種微服務(wù)， Dubbo、Spring Cloud，然后到容器，再到現(xiàn)在的kubernetes的云原生，甚至到可以那個(gè)時(shí)候說是Service Mesh，那么系統(tǒng)實(shí)際上被越來越多的變成無狀態(tài)的，越來越多的變成分布式的。系統(tǒng)變得越來越龐大，隨之給系統(tǒng)的穩(wěn)定性帶來了巨大的挑戰(zhàn)。
穩(wěn)定性保障體系演進(jìn)過程
穩(wěn)定性保障能力
消極自愈
消極自愈治標(biāo)不治本，例如磁盤告警后的自動(dòng)清理和擴(kuò)容，只要產(chǎn)生相關(guān)告警直接進(jìn)行磁盤擴(kuò)容或清理。第一種是全消極自愈，當(dāng)監(jiān)控平臺(tái)出現(xiàn)告警之后直接調(diào)用自動(dòng)化平臺(tái)的操作去做執(zhí)行腳本進(jìn)行恢復(fù)，其實(shí)這種嚴(yán)格來說是一種消極的故障自愈，也沒有什么故障的根因分析，一旦出現(xiàn)問題直接上三板斧（重啟、關(guān)機(jī)、切流）或者是直接執(zhí)行告警恢復(fù)預(yù)案。如果執(zhí)行不了預(yù)案就只能進(jìn)行人工處理直至進(jìn)行問題閉環(huán)。這種自愈主要面向的是一些數(shù)據(jù)庫殺鎖、文件清理、中間件/數(shù)據(jù)庫DOWN等簡單的場(chǎng)景。第二種半消極自愈，這個(gè)半消極自愈是筆者的自己理解，所謂的半消極自愈說的是在執(zhí)行自愈預(yù)案之前先進(jìn)行故障快照的抓取，保留一部分故障現(xiàn)場(chǎng)。當(dāng)然這里還有層意思是說有些故障告警是單一腳本無法進(jìn)行恢復(fù)，需要腳本、API接口、人工判斷，通過流程引擎將這幾個(gè)對(duì)象進(jìn)行串聯(lián)或者并聯(lián)，甚至將上一個(gè)操作的結(jié)果輸出到下一個(gè)結(jié)果來完成一系列的自愈流程來進(jìn)行故障處理。如下圖是一個(gè)簡單的自動(dòng)故障處理流程，告警觸發(fā)之后匹配處理策略，如果匹配成功就進(jìn)行故障快照抓取腳本，再去執(zhí)行腳本動(dòng)作1再到腳本動(dòng)作2，這可能涉及到去調(diào)用業(yè)務(wù)系統(tǒng)的API接口然后觸發(fā)一個(gè)合流的動(dòng)作，將兩個(gè)API調(diào)用的結(jié)果合并在一起輸出至另一個(gè)腳本進(jìn)行執(zhí)行，最后需要人工確認(rèn)是否故障處理完成，人工判斷確認(rèn)執(zhí)行點(diǎn)擊通過結(jié)束故障處理流程。
上面的流程可能看起來有些復(fù)雜，但是在現(xiàn)網(wǎng)出現(xiàn)的故障是有這種情況出現(xiàn)的，這里傳達(dá)了一個(gè)思想，一個(gè)故障的處理流程可能不僅僅只是調(diào)用python、shell腳本進(jìn)行故障的處理，可能還需要去調(diào)用業(yè)務(wù)系統(tǒng)的一些接口，最終還需要進(jìn)行人工確認(rèn)是否已解決此故障來完成這個(gè)故障的自愈。積極自愈
積極的故障自愈，就是在進(jìn)行故障自愈的過程中要對(duì)故障根因進(jìn)行分析，當(dāng)然這種故障也包含了很復(fù)雜的故障處理流程，可能需要拉通各種的運(yùn)維工具，以及需要調(diào)動(dòng)不同的專業(yè)組的人進(jìn)行一起協(xié)同處理故障，像這種告警是一個(gè)流程化的工程，首先是觸發(fā)一個(gè)工單（類似的故障可能不能第一時(shí)間對(duì)故障進(jìn)行服務(wù)）去跟進(jìn)這個(gè)故障推動(dòng)他閉環(huán)，第二是需要人工判斷使用那些腳本，執(zhí)行什么樣的操作去進(jìn)行告警恢復(fù)。
為什么不是ITSM？
不管是消極自愈還是積極自愈，在整個(gè)流程過程中都有提到一個(gè)概念是流程，不管是簡單的還是無法直接自愈的操作都是需要一個(gè)強(qiáng)大的流程引擎對(duì)故障進(jìn)行恢復(fù)。流程引擎一般都是業(yè)務(wù)系統(tǒng)中使用的，幾乎每個(gè)業(yè)務(wù)系統(tǒng)都有自己的內(nèi)部流程，像OA、CRM等這些系統(tǒng)強(qiáng)流程化的。當(dāng)然運(yùn)維行業(yè)中管理側(cè)的系統(tǒng)---ITSM系統(tǒng)，也是一個(gè)強(qiáng)流程的運(yùn)維管理系統(tǒng)。ITSM是通過流程去驅(qū)動(dòng)運(yùn)維工作線上化，推動(dòng)事件、問題的閉環(huán)，對(duì)請(qǐng)求、變更、發(fā)布等流程的記錄，做到事后跟蹤和復(fù)盤。有些人就說是不是可以使用ITSM的流程引擎去實(shí)現(xiàn)不同對(duì)象之間的操作。當(dāng)然ITSM的流程引擎是可以處理這些流程，但是ITSM天生就是用來調(diào)用角色、人等的操作，它的出現(xiàn)是為了讓運(yùn)維工作流程化、線上化，并通過管理來將運(yùn)維流程線上化，因此ITSM主要是用于運(yùn)維流程和標(biāo)準(zhǔn)化管理。運(yùn)維任務(wù)協(xié)同
那我們需要的運(yùn)維流程引擎是一個(gè)什么樣的東西呢，這里與其說是運(yùn)維流程引擎，不如說是運(yùn)維任務(wù)協(xié)同平臺(tái)，是一個(gè)可以連接人、 ITOM 工具、運(yùn)維操作、業(yè)務(wù)應(yīng)用API，以及通過調(diào)動(dòng)ITSM的服務(wù)目錄將背后一系列的動(dòng)作和跨平臺(tái)的不同任務(wù)，利用運(yùn)維任務(wù)協(xié)同平臺(tái)串聯(lián)起來，用以提供順暢、標(biāo)準(zhǔn)化的 IT 運(yùn)維服務(wù)體驗(yàn)，并從 IT 運(yùn)營視角得到的數(shù)據(jù)為運(yùn)維和應(yīng)急保障提供指導(dǎo)。有了這個(gè)既可以調(diào)動(dòng)人、運(yùn)維操作、ITOM工具、業(yè)務(wù)應(yīng)用API等的運(yùn)維任務(wù)協(xié)同平臺(tái)，我們就可以重新定義一些運(yùn)維工作和任務(wù)。通過運(yùn)維任務(wù)協(xié)同平臺(tái)將定義運(yùn)維流程和管理ITSM、IT資產(chǎn)管理的ITOM、運(yùn)維工作的參與者、涉及的業(yè)務(wù)系統(tǒng)、運(yùn)維操作，拉通在一個(gè)軌道上進(jìn)行不同的任務(wù)協(xié)作，最終構(gòu)建統(tǒng)一的運(yùn)維協(xié)作中心。業(yè)界成功經(jīng)驗(yàn)---Service Now
這里以業(yè)界著名的ITSM廠商Service Now為案例，ServiceNow創(chuàng)立于2004年，Service Now的愿景在于借助IT工具，實(shí)現(xiàn)企業(yè)工作流的創(chuàng)建、編排和自動(dòng)化管理等，以簡化和代替企業(yè)的事務(wù)型工作。Service Now擁有全球最為優(yōu)秀的工作流引擎，依托這個(gè)強(qiáng)大的工作流引擎Service Now從ITSM 業(yè)務(wù)起步，不斷的“開花散葉”，目前業(yè)務(wù)已經(jīng)實(shí)現(xiàn)了ITOM、人力資源管理、客戶服務(wù)管理、安全運(yùn)營管理等不同的領(lǐng)域的跨界。從Service Now的實(shí)踐中我們可以總結(jié)出來，上文提到的運(yùn)維任務(wù)協(xié)同平臺(tái)和Service Now的流程引擎是一樣的東西，Service Now借助它的流程引擎開出了ITSM這朵讓同行望塵莫及的“花”，同理當(dāng)我們擁有了運(yùn)維任務(wù)協(xié)同平臺(tái)之后，可以依托此拉通不同的運(yùn)維任務(wù)，開出更多的“花”，甚至可以長出一棵參天大樹。
前文有提到積極的故障自愈是在自愈的過程中既要推動(dòng)執(zhí)行故障預(yù)案，還要去分析故障的根因。下面聊的積極自愈是一個(gè)復(fù)雜的不能通過簡單的流程快速處理的故障，這種故障可能不僅僅需要告警出現(xiàn)之后去關(guān)聯(lián)知識(shí)庫，還需要去關(guān)聯(lián)可觀測(cè)性平臺(tái)的一些指標(biāo)去進(jìn)行關(guān)聯(lián)，以及拉起一個(gè)協(xié)作空間快速的處理故障，最后推動(dòng)故障復(fù)盤。流程如下圖：
當(dāng)故障觸發(fā)的時(shí)候，協(xié)作中心會(huì)去調(diào)用自動(dòng)化執(zhí)行平臺(tái)去抓取相關(guān)的故障快照；同時(shí)會(huì)去知識(shí)庫匹配處理經(jīng)驗(yàn)，如果匹配成功將調(diào)用自動(dòng)化平臺(tái)的執(zhí)行或者是其他的流程完成故障自愈。如果沒有在知識(shí)庫中匹配到故障處理經(jīng)驗(yàn)，協(xié)作中心會(huì)去查詢CMDB（或可觀測(cè)性平臺(tái)）的故障影響范圍，并基于CMDB中相關(guān)資產(chǎn)維護(hù)人拉起一個(gè)專項(xiàng)的應(yīng)急管理組織去處理組織，通過還會(huì)生成一個(gè)事件單或者是故障單同步至ITSM平臺(tái)（故障管理平臺(tái)）。通過建立的故障處理組織，首先就對(duì)故障進(jìn)行響應(yīng)進(jìn)行處理故障。在故障響應(yīng)之后會(huì)通過協(xié)作中心拉起一個(gè)協(xié)同的處理空間，這個(gè)空間使大家在一個(gè)緯度去處理故障，空間里邊會(huì)匯聚監(jiān)控指標(biāo)、調(diào)用鏈、日志、CMDB資產(chǎn)關(guān)聯(lián)關(guān)系、歷史告警等信息，并能看到故障開始到當(dāng)前的處理過程，當(dāng)然還需要一個(gè)工具是讓一二三線工程師可以看到后續(xù)的操作步驟，并可以隨時(shí)介入進(jìn)行故障的處理，在這里我們把這個(gè)工具定義為在線CRT，它的作用主要是可以讓組織空間里邊的人可以同時(shí)看到當(dāng)前故障處理過程中實(shí)時(shí)執(zhí)行的命令，也要具備當(dāng)一線解決不了的時(shí)候可以通過轉(zhuǎn)移轉(zhuǎn)給二線或三線處理。故障處理完成之后協(xié)作中心會(huì)去發(fā)起一個(gè)故障復(fù)盤，去反問故障原因有哪些？我們做什么，怎么做才能確保下次不會(huì)再出現(xiàn)類似故障？當(dāng)時(shí)如果我們做了什么，可以用更短的時(shí)間恢復(fù)業(yè)務(wù)？故障復(fù)盤完成，將回答的故障三問固化到知識(shí)庫，同步將其推送至ITSM進(jìn)行故障閉環(huán)。結(jié) 語
上面介紹的故障處理流程可能非常長，在真實(shí)環(huán)境中肯定是以恢復(fù)故障為主，流程看似很長，其實(shí)通過運(yùn)維協(xié)作中心串聯(lián)起來之后就會(huì)很快的去流轉(zhuǎn)起來，推動(dòng)整個(gè)流程的閉環(huán)。本文主要是介紹的故障處理的過程，也摻雜了一點(diǎn)故障復(fù)盤的東西，真實(shí)的故障管理是包括故障等級(jí)定義（有些告警是不能作為故障的，筆者認(rèn)為只有影響到整個(gè)業(yè)務(wù)系統(tǒng)緩慢、卡頓、hang的告警才能判定為故障）、故障發(fā)現(xiàn)、故障響應(yīng)、故障應(yīng)急、故障恢復(fù)、故障復(fù)盤及持續(xù)改進(jìn)。本文作者：邸仁杰（上海新炬王翦團(tuán)隊(duì)）
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/129214.html
