2022年05月10日
企業(yè)IT故障定位指診斷故障直接原因或根因,故障定位有助于故障恢復(fù)動作更加有效。故障定位通常是整個故障過程中耗時最長的環(huán)節(jié),定位的目標圍繞在快速恢復(fù)的基礎(chǔ)上,而非尋找問題根因,后者由問題管理負責(zé)。通常大部分可用性故障,要借助運維專家經(jīng)驗的假設(shè)判斷或已知預(yù)案的執(zhí)行得到解決,但仍有部分故障,尤其是性能、應(yīng)用邏輯、數(shù)據(jù)故障需要多方協(xié)同與工具支持。故障定位的方法通常包括專家經(jīng)驗驅(qū)動的假設(shè)嘗試、測試復(fù)現(xiàn)、預(yù)案啟動、代碼分析四種,這個過程涉及對日志、鏈路、監(jiān)控、數(shù)據(jù)感知、知識管理五類工具。隨著系統(tǒng)復(fù)雜性不斷提升,依靠專家經(jīng)驗驅(qū)動的假設(shè)嘗試準確率會下降,如何將數(shù)字化手段結(jié)合專家經(jīng)驗,融入到協(xié)同機制中,這考驗故障定位場景的設(shè)計水平。
1.定位方法
1) 專家經(jīng)驗驅(qū)動的假設(shè)嘗試
隨著企業(yè)的應(yīng)用系統(tǒng)架構(gòu)由原來單體架構(gòu)向分布式微服務(wù)架構(gòu)發(fā)展,以及研發(fā)、運維團隊對高可用架構(gòu)的重視與投入,越來越多的系統(tǒng)在服務(wù)級別的可用性、可靠性、健壯性更強,再加上配套的監(jiān)控工具完善,一般的服務(wù)級別不可用故障有更好的應(yīng)對方案。當前運維面臨的故障定位問題,主要是:
海量并發(fā)下,故障的快速傳染,單個服務(wù)異常影發(fā)了大量異常的出現(xiàn),如何在大量異常服務(wù)中判斷根因服務(wù)。
判斷應(yīng)用邏輯層面的異常,比如功能、菜單級別的故障,如何更加主動、從容的找到邏輯上的故障點,并作出應(yīng)急。
應(yīng)用邏輯故障的問題定位與 “故障傳染”場景類似,如何在大量病態(tài)的功能中找到根因功能,并對功能進行降級等恢復(fù)是難點。
判斷數(shù)據(jù)異常產(chǎn)生的異常,數(shù)據(jù)異常不僅僅指數(shù)據(jù)完成不可用,而是在大部分數(shù)據(jù)正常下,找到個別數(shù)據(jù)不可用的問題。
在面對上面的故障時,整體的自動化能力還有較大提升空間,基于運維專家經(jīng)驗驅(qū)動的假設(shè)性嘗試診斷與恢復(fù)仍是當前主要的應(yīng)對手段。要讓運維專家經(jīng)驗發(fā)揮得更好,需要重點關(guān)注四件事:
專家技能的持續(xù)提升。應(yīng)用邏輯、數(shù)據(jù)異常問題對于傳統(tǒng)運維專家通常是黑盒子,運維專家需要轉(zhuǎn)換角色主動去了解應(yīng)用邏輯功能,上下游調(diào)用鏈、數(shù)據(jù)流向、應(yīng)用配置、數(shù)據(jù)庫流水等要素。
運維前移。了解軟件層的黑盒子,除了主動對線上系統(tǒng)進行學(xué)習(xí),還要落實前移工作,比如:標準化前移,推動軟件更加可維護;基礎(chǔ)平臺前移,用平臺推動軟件標準化;交付前移,標準化、自動化軟件交付鏈路;測試前移,圍繞系統(tǒng)穩(wěn)定性進行主動的體驗、接口、壓力測試,提升穩(wěn)定性等等。
技能的沉淀與傳承。依靠經(jīng)驗最大挑戰(zhàn)是應(yīng)對人員不在故障處理現(xiàn)場的問題,技能的沉淀與傳承是運維管理需要考慮的問題。前者針對技能經(jīng)驗的知識化,重點關(guān)注知識生產(chǎn)、保鮮、共享;后者針對崗位設(shè)置、培訓(xùn)、值班管理等機制。
工具賦能。應(yīng)用日志、交易報文、應(yīng)用流水等是了解軟件邏輯和數(shù)據(jù)的主要方案,組織要為專家提供方便的工具。這個思路同樣適用于運維以外的專家,比如在故障協(xié)同中將應(yīng)用日志、功能級的性能等數(shù)據(jù)以在線工具方式分享給研發(fā)、測試團隊也是一個有效的賦能手段。
2) 已知預(yù)案啟動
對于疑難雜癥或重大故障,我們認為故障診斷過程中,應(yīng)該采用兩條操作路徑,一是前面提到的基于專家經(jīng)驗的嘗試性的診斷,另一點是圍繞已知預(yù)案的嘗試啟動。已知預(yù)案指提前對故障場景進行描述,并制定應(yīng)急操作步驟。在預(yù)案的啟動中,我們做了幾件事:
預(yù)案線上化。線上化的預(yù)案主要解決當前線下文檔式預(yù)案不可用、不好用的問題。采用樂高式拼裝的方式,將應(yīng)急策略卡片化,支持將多個策略拼裝成一個應(yīng)急場景下的預(yù)案。
預(yù)案自動化。預(yù)案線上化后就能將預(yù)案的策略自動化、社交化,比如根據(jù)鏈路關(guān)注自動化的觸達應(yīng)急策略到關(guān)聯(lián)方,將預(yù)案應(yīng)急的協(xié)同在社交 IM 進行處置等。具體的預(yù)案場景設(shè)計將在場景部分中進行介紹。
預(yù)案融入故障處置過程。將預(yù)案的執(zhí)行與應(yīng)急處置場景工具整合在一起,作為一個標準化的動作,一方面持續(xù)實戰(zhàn)使用中不斷的發(fā)現(xiàn)預(yù)案存在不足,另一方面故障處置驅(qū)動預(yù)案設(shè)計者更加重視預(yù)案的編寫。
3) 測試復(fù)現(xiàn)
復(fù)雜系統(tǒng)的故障定位必然是一個跨團隊協(xié)同的過程,測試復(fù)現(xiàn)是一個協(xié)同定位的解決方案。從崗位看,測試與 bug 打交道的機會最多,對于邏輯、數(shù)據(jù)引發(fā)的故障更敏感。測試復(fù)現(xiàn)與定位問題用什么方法,因為不專業(yè)不作說明,以下從運維賦能測試復(fù)現(xiàn)問題的角度列一下運維需要提前準備的支持:
讓測試能夠更快的獲得問題描述,問題表現(xiàn)的截圖,工單系統(tǒng)的在線流轉(zhuǎn),或基于 chatOps的信息傳遞都是好的解決方案。
讓測試方便的查生產(chǎn)環(huán)境的異常日志,能看到獲得網(wǎng)絡(luò)服務(wù)的 500 錯誤,還是空指針等等信息。
按接口細分訪問狀況,包括成功率,交易量,耗時等。
定期同步測試系統(tǒng),將生產(chǎn)已知缺陷數(shù)據(jù)在線化,輔助測試定位。
在線獲得配置信息,查看應(yīng)用配置項的生產(chǎn)設(shè)置情況。
4) 代碼分析
雖然開發(fā)可能不清楚復(fù)雜系統(tǒng)完整的上下游關(guān)系,部署架構(gòu),但一定是最清楚具體邏輯、數(shù)據(jù)的人角色。與測試復(fù)現(xiàn)提到的類似,運維也要為研發(fā)團隊提供應(yīng)急協(xié)同的工具。除上面為測試提供的工具適用于研發(fā)外,運維還要為開發(fā)提供線上程序版本、配置信息、各功能號的性能信息等數(shù)據(jù)。性能管理, AIOps等場景的工具應(yīng)用,將有利于研發(fā)團隊在故障定位環(huán)節(jié),提升代碼分析能力。
2. 定位工具
1) 日志
對于運維而言,日志是運維了解硬件及軟件內(nèi)部邏輯的一面窗口。以軟件為例,從系統(tǒng)生命周期看,由于運維沒有參與到軟件的需求分析、系統(tǒng)設(shè)計、編碼開發(fā)、質(zhì)量測試等階段,當系統(tǒng)交接到生產(chǎn)環(huán)境時,軟件日志是運維了解系統(tǒng)運行狀況的重要手段。日志記錄了從業(yè)務(wù)、中間件、系統(tǒng)等全鏈路信息,可以有效監(jiān)控IT系統(tǒng)各個層面,從而有效的調(diào)查系統(tǒng)故障,監(jiān)控系統(tǒng)運行狀況。利用日志,運維可以了解用戶行為操作,服務(wù)請求調(diào)用鏈路,功能調(diào)用是否成功,失敗原因等信息,是故障定位的重要手段,幫助運維人員快速定位問題。
傳統(tǒng)運維依靠人力從日志中排查故障原因,主要通過 grep、sed等指令利用關(guān)鍵詞(error, fail, exception等)進行搜索,或利用基于規(guī)則的日志提取方法,通過傳統(tǒng)方式手動設(shè)置正則表達式來解析日志。這不僅對代碼要求高,而且要求運維人員對系統(tǒng)和業(yè)務(wù)有著豐富的經(jīng)驗。隨著系統(tǒng)的日趨復(fù)雜化,日志顯現(xiàn)出數(shù)量龐大、無固定模式、不易讀懂等特點。僅憑借管理員在海量日志中手動查看日志記錄,需要登陸每一臺服務(wù)器,一次次重定向文件,操作繁瑣, 不利于故障定位。所以,構(gòu)建一體化的日志分析平臺和利用人工智能的技術(shù)對日志進行分析是解決當前日志分析的方向,實現(xiàn)分散日志的歸集,并在日志數(shù)據(jù)之上建立日志數(shù)據(jù)二次加工,提升故障定位能力。
2) 鏈路
這里提的鏈路主要包括縱向與橫向的依賴關(guān)系,縱向關(guān)系指從生產(chǎn)對象的部署關(guān)系建立的從基礎(chǔ)設(shè)施、網(wǎng)絡(luò)、計算資源服務(wù)器、存儲、虛擬機、容器、主機、應(yīng)用系統(tǒng)、應(yīng)用、服務(wù)的關(guān)系,通常圍繞應(yīng)用系統(tǒng)進行擴散;橫向關(guān)系主要從服務(wù)調(diào)用關(guān)系,通過通過業(yè)務(wù)進行構(gòu)建關(guān)系鏈。從技術(shù)實現(xiàn)上,我覺得可以圍繞 CMDB 與 PAAS 平臺兩個平臺建設(shè)之上持續(xù)完善鏈路關(guān)系。其中 CMDB 應(yīng)該將關(guān)系定位為 CMDB 最重要的配置數(shù)據(jù)之一,如果當前的 CMDB 到了以業(yè)務(wù)為中心的配置管理方案,那么集成必要的關(guān)系發(fā)現(xiàn)、關(guān)系繪制構(gòu)建、關(guān)系消費的能力是下一代 CMDB 的重點( CMDB 的發(fā)展可以分為:滿足 IT 資源管理線上化,支撐運維平臺化互聯(lián)互通,以業(yè)務(wù)為中心的配置管理,基于關(guān)系為核心的知識圖譜)。PAAS 平臺,側(cè)重指企業(yè)以微服務(wù)為應(yīng)用平臺,或是面向云原生的應(yīng)用平臺。通常應(yīng)用平臺為了解平臺上的系統(tǒng)的可維護性與可靠性,服務(wù)調(diào)用鏈有配套的解決方案,運維需要對平臺現(xiàn)有鏈路關(guān)系進行在線的獲取。
3) 監(jiān)控
以往,監(jiān)控往往被定位為“監(jiān)測”的角色,即只負責(zé)發(fā)現(xiàn)異常,將報警發(fā)出來即盡到監(jiān)控職責(zé)。站在運維業(yè)務(wù)連續(xù)性保障的最終價值看,監(jiān)控要在“監(jiān)”的基礎(chǔ)上,增加“控”在故障恢復(fù)角度的要求,而要實現(xiàn)“控”前,需要監(jiān)控具備定位問題的能力。監(jiān)控提升故障定位能力,可以考慮以下幾個點:
對于已知異常的監(jiān)控策略,在監(jiān)控發(fā)現(xiàn)問題后,對已知異常探測點結(jié)果進行清晰的描述。
對于多個監(jiān)控告警進行告警事件的收斂管理,基于 CMDB 關(guān)系數(shù)據(jù)進行初步的定位。
利用監(jiān)控數(shù)據(jù)與 AIOps算法,構(gòu)建智能化的故障定位場景應(yīng)用,增加故障定位的能力。
對于監(jiān)控方面的內(nèi)容將有專門的章節(jié)作介紹,這里不再展開。
4) 數(shù)據(jù)感知
數(shù)據(jù)感知不僅僅是將數(shù)據(jù)可視化,而是要從更高維度去感知系統(tǒng)運行狀況。傳統(tǒng)應(yīng)用監(jiān)控主要采用 “點”的方式不斷完善監(jiān)控,即當出現(xiàn)新的漏洞或事件,則在監(jiān)控系統(tǒng)增加相應(yīng)運行“點”的數(shù)據(jù)采集,并加上對數(shù)據(jù)的預(yù)警策略達到預(yù)警的效果。這種“點”的監(jiān)控方式更多的是打補丁的方式,是一種“事后”、“被動”、“加固”的思路,為了提高監(jiān)控能力需要利用每個運維同事的專家經(jīng)驗轉(zhuǎn)變成“事前”、“主動”、“預(yù)防”為主,以“事后”、“被動”、“加固”為輔思路。要實現(xiàn) “事前”、“主動”、“預(yù)防”,需要將以“點”為主的監(jiān)控視角,轉(zhuǎn)變成“面”的視角(可以理解為上帝視角,自上而下),這種”面“的視角是對現(xiàn)有監(jiān)控方式的一個補充,是應(yīng)對應(yīng)用越來越復(fù)雜、業(yè)務(wù)連續(xù)性要求越來越高問題的要求。我覺得數(shù)據(jù)感知有以下的特征:
全景感知。舉一反三,面的思維,主動思考同類的感知,主動消費己有的數(shù)據(jù)庫、日志的數(shù)據(jù)。
數(shù)據(jù)基線。感知系統(tǒng) “健康狀態(tài)”,利用同比、環(huán)比的基線比對,利用多維度組合的可視化、即時的信息推送、數(shù)據(jù)驅(qū)動的自動化操作讓運維能夠更快、更全面的感知異常。
業(yè)務(wù)為中心。關(guān)注影響業(yè)務(wù)的點,比如:是否影響業(yè)務(wù)服務(wù)可用性、性能、功能、體驗。
數(shù)據(jù)驅(qū)動。消費 &落地關(guān)系數(shù)據(jù)庫、內(nèi)存數(shù)據(jù)庫、日志數(shù)據(jù),與關(guān)系/鏈路的配置數(shù)據(jù)多維關(guān)聯(lián),形成評價系統(tǒng)是否“健康”的多維度指標。
5) 知識管理
知識管理是一個大家都知道應(yīng)該要做,但大部分都沒做好的事情。原因可能有很多,比如:在管理上,執(zhí)行環(huán)節(jié)領(lǐng)導(dǎo)關(guān)注度不夠有關(guān),前三天很熱,后續(xù)推進不足,缺少持續(xù)的管理、有效的獎懲措施;在運營上,知識需要融入員工工作流程中,這需要知識的運營方參與運維工作流程的設(shè)計,在流程和線上化場景中整合知識的生產(chǎn)過程;在技術(shù)上,知識庫沒有與運維場景工具整合在一起,知識的生產(chǎn)、加工,與知識的應(yīng)用脫節(jié),知識用得少無法驗證知識數(shù)據(jù)的準確性,引發(fā)對知識的信任問題。但是,可以預(yù)見,隨著系統(tǒng)架構(gòu)復(fù)雜性越來越高,數(shù)據(jù)量越來越大,當前主要依靠運維專家現(xiàn)場經(jīng)驗驅(qū)動的臨斷決策解決問題的模式在未來受到的挑戰(zhàn)會越來越大。尤其是對于未知故障的應(yīng)急管理成為當前運維組織重中之重需要解決的問題。
以手工維護為主的知識庫也許可以向基于下一代智能技術(shù)實現(xiàn)的知識圖譜發(fā)展,增強生產(chǎn)對象與對象關(guān)系的描述能力,將對故障定位起來至關(guān)重要的作用。比如,運維知識圖譜能賦能故障的決策,將運維知識圖譜融入到運維應(yīng)急工具中,可以將運維人員的故障定位決策過程數(shù)字化,構(gòu)建決策支持知識圖譜,借助機器對海量定位決策操作行為進行窮舉式遍歷。如果運維知識圖譜準確性有保證,可以預(yù)見還能夠支持數(shù)據(jù)源/指標/文本異常檢測、基于人工故障庫/數(shù)據(jù)挖掘的故障診斷、故障預(yù)測、故障自愈、 成本優(yōu)化、資源優(yōu)化、容量規(guī)劃、性能優(yōu)化等場景。