作者 | 張旭海

運維挑戰與可觀測性

近 10 年間，企業線上服務與 IT 基礎設施的規模不斷擴大，各種與之匹配的研發實踐、生態如微服務、DevOps、云原生等等也不斷的發展。在 Canonical 發布的 Kubernetes and cloud native operations report 2022 中顯示：超過 40% 的受訪者所在的組織運行了超過 100 臺機器（包括VM、Bare Metal 等），而超過 20% 的受訪者所在的組織，擁有超過 10 個 Kubernetes 生產集群。

企業運維的挑戰

業務復雜度的提升以及規模的擴大，讓運維工作愈發關鍵且困難，而為了快速響應業務變化，對 DevOps 的要求也越來越高。例如在 DORA Four Keys 中提到，對于發布頻率這一指標，精英級別要求能夠按需發布，實現每日變更多次。但發布變更常伴隨著故障。

76% 的 IT 系統故障是由變更引起的。

-- 18 Key Areas Shaping IT Performance Markets in 2020

多數故障都是由變更引起的，而對變更頻率的要求又越來越高，雖然可以通過提升軟件質量來降低故障率，但故障是不可避免一定會發生的。為了降低故障對業務的影響，我們便期望修復故障的時間盡可能的短，但修復故障的前提是定位故障。

66% 的 MTTR 用于識別是什么變化導致了故障。

-- 2022 State of Managing IT Performance Study – Key Takeaways

日趨復雜的系統讓故障根因難以直觀地顯現，畢竟規模越大的業務，其所涉及到的各種應用、服務、基礎設施等環節可能越復雜。因此系統復雜度的上升，導致處理故障的大部分時間都花費在定位問題上。

對系統發生了什么了如指掌是定位問題的前提，因此如何監控整個線上系統，如何獲悉規模巨大的系統的運行狀態，成為了一大挑戰。這種挑戰反過來也促進了可觀測性領域的發展。

可觀測性的目標

對于數字化落地較早的企業，為了應對挑戰，可能早已構建了 APM、NPM 監控系統，以及開源的或是商用的追蹤系統等。而對于傳統企業可能數字化的步伐才剛剛開始，線上服務還停留在從無到有的階段。

那么企業處于自身特定的發展語境下，對可觀測性的要求有什么異同呢？

總體上看，可觀測性代表了對系統形成洞察的能力，可觀測性水平越高，對系統形成的洞察就越深。因此不論企業的數字化程度是低是高，其構建可觀測性能力的目標都是不會改變的。

這些目標包括：

(1) 更全面的收集系統上下文 

系統可觀測的前提是收集數據，各種遙測數據反映了系統當時的上下文。因此數據越多越全，對系統運行的還原度就越高。但由于采樣底噪以及數據管理等問題，既要獲得全面的上下文，又要限制收集的規模，權衡并不容易。

(2) 更有效的關聯各層級數據 

遙測數據是單一而孤立的，基礎設施層關心的數據與業務應用關心的數據可能相去甚遠。數據之間只有建立起關系，人腦才易于從中發現問題，抽絲剝繭。數據形成關聯的有效程度，與能從中獲得洞察的深度成正比。

(3) 更自動化的尋找問題根因 

數據規模可能會指數增長，但人腦的產出只能隨著時間線性增長。因此如何通過自動化的手段，降低人腦的認知成本，縮短人工時間，逐漸變得愈發重要。

不同企業之間可觀測性能力建設的差異，可能主要體現在對上述目標的完成程度上。

企業可觀測性能力的建設是持續深入的過程，那么如何才能衡量現狀，發現不足進而指導未來的方向呢？

可觀測性成熟度模型

StackState 作為一家提供可觀測性解決方案的咨詢公司，發布了一份 《可觀測性成熟度模型》，基于其對真實問題、客戶討論以及技術研究，旨在幫助企業在可觀測性能力建設上作為指導。

成熟度等級

《可觀測性成熟度模型》將可觀測性分為四個等級，從低到高，越高的等級代表越能深入的對系統進行觀測洞察。

Level 1：監控

監控代表了相對古老而簡單的觀測手段：跟蹤數值。

跟蹤的數值通常專注于基本的組件、應用層面的參數指標，如可用性、性能、容量指標等等。每一次對指標的采集將產生一個事件，事件結合某些閾值，則可能引發報警。

作為最初級的可觀測性，通過跟蹤數值和指標報警的能力，企業能夠獲悉組件或應用的健康狀態，并在出現故障后得到通知。然而，跟蹤數值加報警的形式，的確能告訴運維人員組件出了故障，但故障的原因是什么，需要聯系誰來解決該問題，都無法在這一級別得到很好的處理。

此外，隨著時間的推移，越來越多的指標項被加入監控系統，結果一個問題可能會導致一連串的指標報警，從而出現 “到處亮紅燈，但不知道發生了什么” 的窘境。

Level 2：可觀測性

可觀測性是可觀測性成熟度模型的第二個等級（名字起得差強人意）。由于上一級別遺留的問題，即只知道出了故障但難以得知故障產生的具體原因。因此第二級的目標就是能確定系統不工作的原因。

第二級可觀測性，通常可以采用 “指標”、“日志”、“跟蹤” 這三種關鍵類型的遙測數據來提供系統洞察力。“指標” 與上一級的跟蹤數值基本一致。“日志”是對系統中發生事件的帶時間戳的記錄。”跟蹤“則能顯示數據是如何從頭至尾流經系統的。

實際上，我們會發現這三種關鍵數據（某些文章稱之為三大支柱）已經廣泛的應用在了成熟的微服務系統中，圍繞著“三大支柱”的各種解決方案也層出不窮。總之，通過合理的方案采集這些遙測數據，并展示在儀表板上，就實現了第二級的可觀測能力。

誠然，借助”三大支柱“的有力支持，第二級可觀測能力能夠更廣泛而全面的了解整個系統的運行狀態。但隨著系統規模的擴大，遙測數據會越來越多，不同的遙測數據也可能會存在于不同的系統中（數據孤島）。那么當出現問題時就需要通過人工從大量遙測數據中抽絲剝繭，關聯因果關系。隨著規模的擴大，受限于人力排查，MTTR 的時間也會不斷延長。

Level 3：因果可觀測性

通過人工建立數據相關性，低效且不直觀。因果可觀測性，作為第三個級別，能夠通過某些手段揭示這種相關性，從而達到找到事件發生的原因且確定其對整個系統影響的目的。

具體通過何種手段建立相關性，將在下一節描述。那么假如已經實現了因果可觀測性能力，可能會遇到的新的挑戰可能是什么？

如何對數據規范化，如何長期存儲并高效使用這些數據可能會是下一階段的挑戰。另外，巨大的數據量也會導致即使揭示了數據的相關性，但仍然需要耗費大量時間來從噪音中分離出有用的信號。

Level 4：使用 AIOps 的主動式可觀測性

通過 AI 和 ML 的方式從堆積如山的數據中尋找模式，從而能幫助團隊更快的發現問題。在指標報警和警告中找到模式的變化，可以幫助團隊提前預知可能發生的故障，進而實現預防性的、無事故的運維目標。

AIOps 能夠提升效率，提高根因分析的準確率，甚至預測異常和實現系統自愈。

因果可觀測性

從前面可觀測性的四個成熟度等級可以發現，可觀測性成熟度第二級別，得益于開源技術的成熟，是目前多數系統能夠達到或是已經處于的位置。而更進一步，達到因果可觀測性，則是相對清晰的發展方向。那么，如何實現因果可觀測性的目標，建立數據之間的相關性呢？

《可觀測性成熟度模型》中給出的方法，是建立時間序列下的拓撲結構變化視圖。

對系統進行故障根因調查時，先看看系統 “發生了哪些變化”，是一個合理的切入點。畢竟大多數故障都是因系統發生了變更而引起的，比如新的代碼部署、配置變更、自動擴縮容等等。

但復雜的系統可能會發生不止一處變化，如果能對比故障發生前后，整個系統棧的拓撲結構變化以及組件之間的關系變化，就能清晰的辨別出變化點及其之間的關系。

拓撲結構是系統內所有組件的地圖，它跨越了所有層次，是離散組件之間關系和依賴的集合。

現代環境由許多動態層、微服務、無服務器應用和網絡技術組成，因此在你的可觀測性組合中加入最新的拓撲結構，對于區分因果關系至關重要。拓撲結構為數以千計的未連接的數據流提供了錨點，使它們具有結構性，使以前看不見的連接變得可見。拓撲可視化讓你在全棧活動的背景下查看來自網絡、基礎設施、應用程序和其他領域的遙測數據；它還為你提供了重要的背景，讓你知道當某些事情發生時，你的業務是如何受到影響的。

--《可觀測性成熟度模型》

來源：《可觀測性成熟度模型》

如上圖所示，將原本孤立的數據比如服務的注冊發現、自動化部署、請求追蹤等等數據匯聚，形成完整的拓撲結構，那么第一級與第二級已經實現收集的各種遙測數據就都可以掛載在拓撲圖上。

此外，單有拓撲圖還不夠。對實施自動化運維的現代系統環境中，頻繁的發布、不斷變化的基礎設施以及動態擴縮容使得拓撲結構變化的很快，處理問題時刻的系統拓撲，可能已經與發生問題時刻完全不同了。

因此，除了構建拓撲結構來關聯數據，留存基于時間的快照也非常關鍵。一旦擁有了隨時間變化的拓撲結構快照，就可以在時間線上自由的對比拓撲的變化并查看對應的遙測數據。

來源：《可觀測性成熟度模型》

透過時間序列下的拓撲結構視圖，數據孤島被彌合起來，大大加快了根因分析的速度。關聯起來的數據也易于建立模式，為自動化分析奠定基礎。當然，建立這樣的數據模型并不容易，除了技術上的挑戰，可能還涉及組織上的變革。目前已經有例如 OpenTelemetry 這類開放標準，嘗試先從遙測數據收集的角度建立初步的關聯，雖然遙測數據只是第一步，但也是一個良好的開始。

可觀測性的發展方向

成熟度模型為企業可觀測性演進的方向提供了階段性的參考，那么在建立系統可觀測性過程中，為了覆蓋企業需求，具體需要關注什么樣的能力呢？有哪些技術可以引領可觀測性向著更高的成熟度而演進呢？

Gartner 在 2022 年年中發布的 Critical Capabilities for Application Performance Monitoring and Observability 梳理了APM 和可觀測性的六項關鍵能力：

• 應用程序調試及分布式剖析（ADDP）：識別代碼內的缺陷及錯誤的根源，來緩解性能下降問題
• 行為分析：支撐對用戶及應用行為的探索和分類
• 業務分析：通過統計各項業務 KPI （如轉化率、棄購率、業務健康度）來為營銷人員和應用開發者提供對整個業務條線的洞察力
• IT 服務和基礎設施監控：以類似 SLA、OLA、SLO 的形式為開發者、DevOps、運維團隊等提供基礎設施、關鍵服務的健康度
• 根因分析：通過 APM 等技術建立問題、原因、影響的關系鏈條，支撐故障修復
• 運行時應用程序自我保護（RASP）：在運行時識別易受攻擊的組件并在一定程度上阻止風險請求

以上六大關鍵能力，從包括開發者、運營者、管理者等多個視角覆蓋了不同角色對可觀測性的要求，在通往因果可觀測性，甚至是 AIOps 的主動式可觀測性的道路上，對上述能力的演進要求，可能會聚焦在以下兩個方面：

(1) 如何更全面的收集數據，更好的聚合、關聯數據，避免數據孤島

在鏈路追蹤和性能優化等場景下，傳統可觀測系統能提供的數據更多在應用層面，而系統、內核以及硬件層面的數據，通常不易獲取，且難以關聯。通過 eBPF 技術獲取底層棧的信息并與上層棧數據進行關聯，這種解決方案逐步貼近了“全棧、全鏈路”的追蹤目標，很可能會成為今后鏈路追蹤的標配。

(2) 如何主動的基于數據洞察形成建議，引導人類做出管理決策

收集的數據越全面，關聯越多，數據規模勢必越來越大，目前很多大規模企業的觀測數據規模早已超出了人力所能處理甚至理解的程度。今后通過 AI 來幫助人類處理和分析數據也許是必然的結果，在以 ChatGPT 為代表的大語言模型日趨成熟的今天，結合企業自身垂直領域的觀測數據進行深度訓練而得到的增強 AI，預計能夠為人類提供更準確和理性的決策。

結語

本文通過介紹《可觀測性成熟度模型》，描述了企業可觀測性演進的階段性參考。在成熟度模型中，因果可觀測性是指通過建立數據之間的相關性來打破數據孤島從而建立對數據更深層次的認知。可以基于時間序列下的拓撲結構變化視圖的方法來實現因果可觀測性。

可以預見，企業對可觀測性的重視程度會越來越高，未來通過更加成熟的可觀測性能力，企業不僅能洞察在線服務的運行狀況，還可以支撐商業分析、精細化成本管理、自動化運維等多種場景的需要。