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