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