前言
在 StackState，我們在監控和可觀測性領域工作了八年。 在這段時間里，我們與無數 DevOps 工程師、架構師、SRE、IT 運營負責人和 CTO 進行了交談，我們一遍又一遍地聽到了同樣的掙扎。
今天的消費者已經習慣了始終有效的偉大技術。 他們對中斷或性能問題幾乎沒有容忍度。 這些期望促使企業通過頻繁發布、更快的響應和更高的可靠性來保持競爭力。 與此同時，向基于云的應用程序（及其所有不斷變化的功能、微服務和容器）的轉變使 IT 環境比以往任何時候都更加復雜和難以操作和監控。
因此，我們在全球范圍內展開的監控挑戰中看到了很大的共性，例如客戶描述的這個豐富多彩的問題：
“當基礎設施、存儲、網絡設備或類似的東西出現重大問題時……每次我們都看同一部電影。監控會變成紅色、紅色、紅色，成千上萬的警報，沒人知道根本原因是什么。 每個人都很恐慌——真正的混亂。”
—— Georg H?llebauer，APA-Tech 的企業指標架構師
八年前我親眼目睹了這個問題，當時我是荷蘭一家大型銀行的兩名顧問團隊的一員，幫助他們提高關鍵任務應用程序的可靠性。 他們是一家成熟的企業，針對復雜的環境配備了多種監控工具，但他們無法快速找到問題的根源。 由于許多孤立的工具和缺乏統一的 IT 環境視圖，客戶體驗受到直接影響。 當出現問題時，找到并解決核心問題的時間太長了。 我們知道我們必須找到更好的方法，而我們為滿足這家銀行的需求而構建的技術成為 StackState 的基礎。
自從我們在 2017 年發布了最初的監控成熟度模型以來，很明顯，最初的監控工具——它只是在出現問題時通知 IT 團隊——對許多其他組織來說也不再足夠了。 今天的工程師需要立即了解問題的優先級和背景：對客戶體驗和業務結果有何影響？ 那么，如果影響很大：它為什么會崩潰，我們如何修復它？
可觀測性的概念已經從監控演變為回答這些問題。 可觀測性對于維持業務成功所需的服務可靠性水平至關重要。 不幸的是，在監控和可觀測性空間中導航是很困難的，尤其是當 AIOps 進入畫面時。 許多供應商在市場上大放異彩，新的開源項目層出不窮。 很難知道誰真正做了什么，更難知道哪些能力真正重要。
可觀測性成熟度模型基于對實際環境中實際問題的廣泛經驗、與客戶和潛在客戶的討論、對最新技術的研究以及與 Gartner 等領先分析公司的對話。 我們希望它能幫助您在黑暗中發光。 我們的目標不是向您展示您的可觀測性之旅應該是什么樣子的完美模型。 我們知道它不是那樣工作的。 引用一位著名的英國統計學家的話，“所有模型都是錯誤的，有些是有用的。”
相反，我們編寫此可觀測性成熟度模型是為了幫助您確定您在可觀測性路徑上的位置，了解前方的道路并提供地圖以幫助您找到自己的方式。
愿此模型對您的旅途有用！
Co-founder and Chief Technology Officer
StackState
簡介：為什么要使用可觀測性成熟度模型？
監控作為 IT 運營團隊深入了解其系統的可用性和性能的一種方式已經存在了幾十年。 為了滿足市場需求、更快地創新并更好地支持業務目標，IT 組織需要更深入、更準確地了解其技術環境中正在發生的事情。 獲得這種洞察力并不容易，因為當今的基礎設施和應用程序跨越多種技術，使用多種架構，并且本質上更加動態、分布式和模塊化。
變化也是 IT 的一種生活方式，研究表明 76% 的問題是由變化引起的。為了在面對所有這些挑戰時保持可靠性，公司的監控策略必須發展為可觀測性。
66% 的 MTTR 用于識別導致問題的變化
大多數企業發現很難找到正確的監控策略來可靠地管理他們的環境。 超過 65% 的企業組織擁有 10 多個監控工具，通常作為孤立的解決方案運行。這種分離的結構限制了 SRE 和 IT 運營團隊快速檢測、診斷和解決性能問題的能力。 出現問題時，團隊會嘗試通過組合團隊、流程和工具，或通過手動拼湊孤立的數據片段來找到根本原因。 這種傳統的監控方法非常耗時，并且無法提供改善業務成果所需的洞察力。 故障排除速度太慢，您最重要的面向客戶的系統可能會停機數小時，從而導致數百萬美元的收入損失。
向動態云、容器、微服務和無服務器架構的轉變，加上維護混合環境和遺留記錄系統的需要，進一步加劇了對更高級功能的需求。
云和容器遷移推動了對更高可觀測性成熟度的需求
可觀測性實踐已經發展以滿足這些需求，將監控方面的進步與更全面的方法相結合，提供更深入的洞察力和對跨技術環境正在發生的事情的更準確的理解。 可觀測性成熟度模型定義了可觀測性演變的四個不同級別，如下頁表 1 中所述。
| 等級 | 目標 | 功能 |
|---|---|---|
| 1. 監控 | ? 確保各個組件按預期工作。 | ? 跟蹤 IT 系統中各個組件的基本健康狀況 ? 查看事件； 觸發警報和通知 ? 告訴您出了點問題...但不是什么 |
| 2. 可觀測性 | ? 確定系統不工作的原因。 | ? 通過觀察其輸出來深入了解系統行為 ? 側重于從指標、日志和跟蹤中推斷出的結果，并結合現有的監控數據 ? 提供基線數據以幫助調查問題所在 |
| 3. 因果可觀測性 | ? 查找事件的原因并確定其對整個系統的影響 | ? 提供更全面的見解以幫助確定問題的原因 ? 建立在第 1 級和第 2 級基礎上，添加了跟蹤 IT 堆棧中拓撲結構隨時間變化的能力 ? 生成廣泛的相關信息，有助于減少確定問題所在、問題發生的原因 |
| 4. AIOps 的主動可觀測性 | ? 分析大量數據，自動響應并防止異常成為問題。 | ? 使用人工智能和機器學習在大量數據中尋找模式 ? 將 AI/ML 與 1-3 級數據相結合，提供最全面的堆棧分析 ? 及早發現異常并發出足夠的警告以防止故障 |
表 1：定義可觀測性成熟度級別
每個級別的可觀測性都建立在先前級別建立的基礎之上，以增加捕獲、跟蹤和分析數據的能力。 新功能支持在每個階段進行更深入的觀察，從而提高 IT 可靠性和客戶滿意度，如下面的圖 1 所示。 雖然您可以通過增強流程在某個級別內略微改進結果，但大多數團隊需要收集新類型的數據以推進到下一個成熟度級別并實現更大的收益。
可觀測性成熟度模型基于與跨行業企業的研究和對話，并已得到其他從業者、分析師和思想領袖的驗證。 它旨在幫助您：
? 了解不同類型的數據以及監控和可觀測性實踐如何幫助您的組織收集可操作的信息。
? 了解監控、可觀測性和AIOps 之間的區別。
? 評估您的組織當前的成熟度水平。
? 引導您的團隊達到更高的成熟度。
使用此模型了解您可以采取哪些清晰的步驟來提高組織中的可觀測性，以便您最終可以向客戶交付更可靠和更具彈性的應用程序。
第一級：監控
目標：確保各個組件按預期工作。
第一級，監控，對 IT 來說并不陌生。 監視器跟蹤單個系統組件的特定參數，以確保它保持在可接受的范圍內。 如果該值超出范圍，監視器將觸發一個操作，例如警報、狀態更改、通知或警告。
傳統監控通常包括應用程序性能監控 (APM)、基礎設施監控、API 監控、網絡監控和各種其他以域為中心的工具，用例是“當某些事情運行不滿意時通知我”。 您可以根據交通燈顏色來考慮監控：
- 組件可用且健康（綠色）
- 組件存在風險（橙色或黃色）
- 組件損壞（紅色）
監控著眼于預定義的值集和預定義的故障模式集。 它關注基本的組件級參數，例如可用性、性能和容量，并生成報告監視值狀態的事件。
事件是 IT 環境中值得注意的變化。 盡管事件可能純粹是提供信息，但它們通常描述需要采取行動的關鍵事件。 事件可能會觸發通過各種渠道到達的警報或通知，例如電子郵件、聊天、移動應用程序或事件管理系統。
作為實現可觀測性的第一步，實施監控以獲得對各個組件的健康和狀態的基本洞察，并在出現問題時收到通知。 下面的表 2 概述了級別 1 的關鍵功能。
| 說明 | |
|---|---|
| 第一級：監控 | 使用基本的交通信號燈監控來了解構成 IT 服務的各個組件的可用性。 |
| 系統輸入 | 事件和組件級指標（例如，“API 響應時間高于我們五秒的 SLO”） |
| 系統輸出 | 警報或通知（例如，“訂單履行服務已關閉”） |
| 你得到什么 | ? 基本信息，例如組件的健康狀態——它在工作嗎？ ? 出現問題時的警報和通知 ? 最簡單的入門方式； 許多開源和 SaaS 解決方案可用 |
表 2：第 1 級總結
下一步：可觀測性
監控使您對整體環境狀態的了解有限。 它向您顯示單個組件的運行狀況，但通常沒有關于全局的信息。 它會告訴您出現問題，但不會告訴您原因、聯系誰，也不會告訴您原始問題出現的時間和地點。
設置和維護監控檢查和通知渠道需要大量手動工作。 在第 1 級，您還需要手動進行根本原因分析和影響分析，并且您的數據集有限。 調查問題的根源需要時間。 此外，單個問題可能會導致來自多個組件的警報風暴，導致進一步的混亂和延遲查明根本原因。
雖然監控可以檢測到有限數量的已知類型的故障或“已知的未知數”，但第 2 級可觀測性可以幫助您發現未知和意外的故障模式或“未知的未知數”。 當您從級別 1 升級到級別 2 時，您將獲得更深入的信息，從而更好地了解服務的可用性、性能和行為。
第二級：可觀測性
目標：確定系統不工作的原因。
為了讓當今復雜和動態的 IT 系統可靠地運行，您不僅需要知道什么在工作（監控），還需要了解它為什么不工作（可觀測性）。
傳統監控跟蹤組件或系統的基本健康狀況。 隨著時間的推移，可觀測性自然演變，以提供對系統行為的更深入洞察。 當出現問題并且您的團隊收到警報時，您需要快速弄清楚，“發生了什么事？ 我們在哪里、什么時候、為什么以及給誰打電話？” 可觀測性數據可以幫助您回答這些問題。 在其完全成熟（第 4 級）時，可觀測性在適當的上下文中提供您需要的所有數據，以自動檢測和修復問題，甚至主動識別和預防問題。
當彈出警報時，您希望了解系統的狀態以找到問題的根源。 在第 2 級，可觀測性通常通過關注三種關鍵類型的遙測數據來提供系統洞察力：指標、日志和跟蹤。 可觀測性的這三大支柱是從 IT 組件（例如微服務、應用程序和數據庫）中收集的，以提供對系統的整體視角。 系統的行為。 每個支柱提供不同類型的信息，如下表 3 所示。
| 支柱 | 定義 |
|---|---|
| 指標 | 幫助您了解服務性能和狀態的數值測量——例如，著名的四個黃金信號：延遲、流量、錯誤率和飽和度。 |
| 日志 | 系統中發生的相關事件（例如事務、警告、錯誤）的時間戳記記錄，可幫助您了解系統在給定時間點的行為。 |
| 追蹤 | 顯示數據如何從端到端流經應用程序的詳細快照（例如，用戶請求），這有助于解決性能問題，有時還可以在代碼級別了解您的應用程序的執行情況。 |
表 3：可觀測性的三大支柱
這三大支柱以及事件和警報通常繪制在儀表板上，因此團隊可以輕松跟蹤重要活動。 一些可觀測性工具提供開箱即用的儀表板，將這些不同類型的數據匯集在一個屏幕上，并允許您深入研究它們以進行進一步調查。
2 級數據比 1 級數據具有更大的廣度和深度，并且它通常涉及將整個環境中的一些數據整合到單個視圖中。 如果您想要獲得更多見解，您可能需要構建額外的儀表板，尤其是當您的環境有多個域并且您正在使用多個監控工具時。
| 說明 | |
|---|---|
| 第 2 級：可觀測性 | 除了事件和健康狀態之外，還可以通過捕獲指標、日志和跟蹤來觀察 IT 環境的行為。 |
| 系統輸入 | 1 級輸入 + 綜合指標、日志和跟蹤 |
| 系統輸出 | 1 級輸出 + 帶有圖形、儀表、火焰圖、日志等的綜合儀表板。 |
| 你得到什么 | ? 通過從更多來源收集更多數據，更深入、更廣泛、更全面地了解整個系統的健康狀況，從而更好地支持問題診斷 ? 除已知故障類型外，還能夠發現未知故障模式 ? 從各種類型的數據中獲得有益的洞察力——例如，跟蹤有助于識別性能瓶頸，指標可提供出色的 KPI，日志可用于查找軟件缺陷 |
表 4：2 級總結
那么挑戰就變成了如何解決來自太多儀表板的信息。 在第 2 級，您可以通過手動關聯數據來推斷事件的可疑原因，但這種方法通常涉及跨系統的復雜手動查詢。
在第 2 級，團隊尚未開發出一種自動化方法來統一和關聯來自各種工具和領域的孤立數據，因此查明問題的根本原因仍然是勞動密集型和耗時的。 因此，MTTD 和 MTTR 高于它們應有的水平，與較高成熟度水平相比，客戶受到的不利影響更大，收入損失更多。
下一步：因果可觀測性
可觀測性會產生大量數據，并且整理出有意義的信息可能很困難。
在第 2 級，您的團隊可能面臨數據孤島和數據量的挑戰，這會導致跨域和跨團隊故障排除效率低下。
當出現問題時，因為沒有人知道問題出在哪里，所以涉及的人太多，導致事件乒乓球和推諉游戲。 您可能需要構建臨時解決方案來查詢多個可觀測性孤島以解決單個問題。 創建這些查詢需要從業者具備開發技能、數據結構知識和對系統架構的理解。
此外，第 2 級中典型的以遙測為中心的孤立視圖通常需要大量手動工作才能提取可操作的見解。 設置高效的儀表板可能需要相當長的時間，并且需要持續維護。 根本原因分析、影響分析和警報降噪對于維護可靠和有彈性的堆棧很重要，但這些活動在這個級別上具有挑戰性。
注意：團隊越來越多地采用 OpenTelemetry 標準來促進指標、日志和跟蹤的捕獲。 OpenTelemetry 非常有助于有效地收集這些類型的數據，但它并不是為了彌合孤島、為數據創建更好的上下文或分析數據而設計的。
為了進入第 3 級并了解您的可觀測性數據是如何相關的，您需要為 IT 環境中的數據孤島中的事件、日志、指標和跟蹤提供上下文。 在第 3 級，因果可觀測性，您可以獲得業務流程、應用程序和基礎架構的精確拓撲圖，并且您可以跟蹤它是如何隨時間變化的。 當出現問題時，您可以結合自動化使用此上下文數據來快速確定問題的原因，而無需手動處理不相關的數據孤島。
級別 3：因果可觀測性
目標：找到事件的原因并確定其對整個系統的影響。
毫不奇怪，大多數故障是由系統中某處的更改引起的，例如新代碼部署、配置更改、自動縮放活動或自動修復事件。 當您調查事件的根本原因時，最好的起點是找出發生了什么變化。
要了解是什么變化導致了問題以及什么影響在您的堆棧中傳播，您需要能夠看到堆棧組件之間的關系如何隨時間變化：
? 問題開始時堆棧是什么樣子的？
? 哪些組件受到影響？
? 所有警報如何關聯？
我們將此級別的洞察力稱為因果可觀測性，它可以讓您跟蹤堆棧中的因果關系，即因果可觀測性——它建立在第 1 級和第 2 級奠定的基礎之上。
“從拓撲中的數據導出模式將建立相關性并說明隱藏的依賴關系。 使用拓撲作為因果關系確定的一部分可以大大提高其準確性和有效性。”
—— Gartner? AIOps 平臺市場指南，2022 年 5 月，Pankaj Prasad、Padraig Byrne、Gregg Siegfried
拓撲是因果可觀測性的第一個必要維度。 拓撲是 IT 環境中所有組件的映射，它跨越所有層，從網絡到應用程序再到存儲，顯示一切是如何相關的。 拓撲結合了組件之間的邏輯依賴性、物理接近性和其他關系，以提供人類可讀的可視化和可操作的關系數據。
拓撲描述了環境中離散組件之間的一組關系和依賴關系，例如，業務服務、微服務、負載平衡器、容器和數據庫。
在當今的現代環境中，隨著新代碼不斷被推入生產環境以及底層基礎設施的快速變化，拓撲結構也在迅速發展。 管理這些動態環境需要能夠跟蹤拓撲隨時間的變化（時間序列拓撲），為堆棧中發生的活動提供歷史和實時上下文。
現代環境由如此多的動態層、微服務、無服務器應用程序和網絡技術組成，因此向您的可觀測性組合添加最新拓撲對于區分因果關系至關重要。 拓撲為數千個未連接的數據流提供錨點
賦予它們結構，使以前不可見的連接可見。 拓撲可視化讓您可以在全棧活動的上下文中查看來自網絡、基礎設施、應用程序和其他領域的遙測數據； 它還為您提供了重要的背景信息，讓您了解發生故障時您的業務會受到怎樣的影響。
然而，對于大多數公司而言，僅添加拓撲不足以提供因果可觀測性。 尤其是在當今具有微服務、頻繁部署、不斷變化的云資源和上下旋轉的容器的動態現代環境中，拓撲結構變化很快。 您的堆棧現在看起來可能不是問題剛開始時的樣子。 因此，第二個維度對于創建因果可觀測性的基礎是必要的：時間。
最后，要了解現代 IT 環境的動態行為并獲得實現因果可觀測性所需的上下文，您需要將環境的拓撲與其關聯的指標、日志、事件和跟蹤數據關聯起來。
在第 3 級，與遙測數據相關的拓撲和時間的其他維度向您顯示跨不同層、數據孤島、團隊和技術的任何更改或故障的原因和影響——顯著縮短解決時間和業務成果。 您還具備開始自動化根本原因分析、業務影響分析和警報關聯的基礎。 更高級的 AIOps 也需要這種更深層次的數據，正如您將在第 4 級中了解到的那樣。
建立因果可觀測性和 AIOps 基礎的 4 個關鍵步驟
- 整合：首先，您需要確保整合了來自整個企業的數據堆放在一個地方，這樣您就可以看到完整的視圖。
- 收集拓撲數據：接下來，您需要構建環境的拓撲圖，這是堆棧中組件的映射，顯示它們如何相互關聯。 可視化拓撲可以快速回答以下問題：“哪個組件依賴于其他組件？ 如果一項服務失敗，還有什么會受到影響？”
- 關聯：您需要關聯所有這些統一的數據，這樣您的整個 IT 環境就可以作為一個整體進行分析，甚至可以跨孤島進行分析。 拓撲中的每個組件都需要與其關聯的指標、日志、事件和跟蹤數據相關聯。
- 隨著時間的推移跟蹤一切：最后，如果您想了解一個組件中的更改如何在您的堆棧中傳播，您需要將您的拓撲數據與隨時間變化的指標、日志和跟蹤數據相關聯。
| 說明 | |
|---|---|
| 級別 3：因果可觀測性 | 通過單個拓撲將遙測數據（指標、跟蹤、事件、日志）關聯起來。 隨著時間的推移關聯所有數據以跟蹤變化在您的堆棧中傳播。 |
| 系統輸入 | 級別 1 和 2 + 時間序列拓撲級別 |
| 系統輸出 | 1 和 2 + 相關拓撲、遙測和時間數據顯示在上下文可視化中，顯示堆棧中更改的影響 |
| 你得到什么 | ? 通過統一時間序列拓撲中的孤立數據，獲得統一、清晰、相關的環境狀態上下文視圖 ? 通過拓撲可視化和分析了解因果關系，顯著加快根本原因識別和解決時間 ? 基本自動化調查的基礎，例如根本原因分析、業務影響分析和警報關聯 ? 自動將與同一根本原因相關的警報集中在一起，從而減少噪音和干擾所需的上下文 ? 能夠可視化網絡、基礎設施和應用程序事件對業務服務和客戶的影響 |
表 5：第 3 級總結
下一步：使用 AIOps 主動觀察
如上所述，Gartner 指出拓撲可以大大提高準確性和有效性
因果決定。 第 3 級是向前邁出的一大步，但統一來自不同孤島的數據在數據規范化、相關性和質量方面提出了挑戰，這些挑戰可能需要新功能甚至組織變革來解決。 此外，很難大規模收集和操作高質量的拓撲數據，尤其是在不太現代化的環境中。
每個拓撲源都需要不斷流入主拓撲，因此您需要確保您的系統能夠隨時間存儲拓撲。 隨著時間的推移存儲與遙測數據相關的拓撲結構提出了更大的挑戰。
“隨著十幾個或更多不同領域的數據量達到或超過每分鐘千兆字節，人工手動分析數據以滿足運營預期已不再可能，更不實用。”
—— Gartner? AIOps 平臺市場指南，2022 年 5 月，Pankaj Prasad、Padraig Byrne、Gregg Siegfried
在制定實施計劃時考慮這些問題。 另請記住，第 3 級數據的速度、數量和種類通常如此之大，以至于要實現您的總體可靠性目標，可能需要 AI 來幫助將信號與噪聲分開。 當您進入第 4 級時，您可以在第 1-3 級之上添加用于 IT 運營的人工智能 (AIOps)，以獲得更準確的洞察力。
第 4 級：AIOps 的主動可觀測性
目標：分析大量數據，自動響應事件并防止異常成為問題。
第 4 級，使用 AIOps 的主動可觀測性，是最高級的可觀測性。 在此階段，用于 IT 運營的人工智能 (AIOps) 被添加到組合中。 在監控和可觀測性的背景下，AIOps 是關于應用人工智能和機器學習 (ML) 對堆積如山的數據進行分類，以尋找模式
? 推動更好的回應
? 盡快
? 由人和自動化系統共同完成。
在 Gartner 2022 年 5 月由 Pankaj Prasad、Padraig Byrne 和 Gregg Siegried 撰寫的“AIOps 平臺市場指南”中，Gartner 通過以下方式定義了 AIOps 平臺的特征：
“AIOps 平臺分析遙測和事件，并確定有意義的模式，這些模式提供了支持主動響應的見解。 AIOps平臺有五個特點：
1.跨域數據攝取和分析
- 資產關系和依賴的隱式和顯式來源的拓撲組裝
- 與事件關聯的相關或冗余事件之間的關聯
- 模式識別以檢測事件、其主要指標或可能的根本原因
- 可能補救協會”
我們對 AIOps 的看法與 Gartner 相同。 AIOps 建立在該成熟度模型中先前級別的核心功能之上——例如收集和操作數據、拓撲組裝和數據關聯——并添加了模式識別、異常檢測和更準確的問題修復建議。 因果可觀測性是一個必要的基礎：時間序列拓撲提供了一個必要的框架。
AIOps 可以幫助團隊更快地發現問題，甚至可以完全預防問題。 AI/ML 算法尋找警告、警報和故障之前的模式變化，幫助團隊了解服務或組件何時開始偏離正常行為，并在出現故障之前解決問題。
“發現異常很容易，因為它們一直都在發生。 當您每天收集十億個事件時，每兩分鐘就會發生一百萬分之一的事件。 可觀測性工具的關鍵是發現與手頭問題相關的異常，然后從可能相關的日志文件/指標中鏈接其他信息。 通過在上下文中顯示相關信息，操作員可以更快地找出問題的潛在根本原因。”
– Gartner?“Innovation Insight for Observability”，2022 年 3 月，Padraig Byrne 和 Josh Chessman
一盎司的預防勝過一磅的治療。 有什么比完全阻止事件發生更好的提高可靠性的方法呢？
然而，異常經常發生。 它們并不一定意味著會發生問題，也不意味著補救應該是高優先級。 AIOps 有助于確定哪些異常需要注意，哪些可以忽略。
AIOps 的另一個可觀測性目標是通過 IT 服務管理 (ITSM) 和自我修復系統推動自動修復。 例如，如果這些系統接收到不正確的根本原因輸入，它們可以自我糾正錯誤的問題并導致更大的問題。 AIOps 提供更準確的輸入，從而提高其有效性。
在第 4 級，您應該注意到更高效和無事故的 IT 運營，提供更好的客戶體驗。 為實現這些目標，設置 AIOps 以超越孤島并攝取從整個環境中收集的數據。 AI/ML 模型應該分析我們在之前級別討論的所有可觀測性數據類型：事件、指標、日志、跟蹤、更改和拓撲，所有這些都隨著時間的推移而關聯。
注意事項：不要跳過第 3 級
AIOps 的主動可觀測性是確保 IT 系統可靠運行的最佳方式，但直接進入第 4 級并跳過第 3 級中的因果可觀測性步驟（數據整合、拓撲、所有數據流隨時間的關聯）是錯誤的 ).
此可觀測性成熟度模型中的每個級別都建立在先前級別建立的能力之上，但擁有完整的基礎對于第 4 級的成功最為重要。如果您在沒有全面數據基礎的情況下應用 AI/ML，您實際上可能會造成損害。 例如，假設您在自動自我修復系統的前端使用 AI/ML。 如果算法確定的根本原因不正確，則自我修復系統會嘗試糾正錯誤的事情，并可能進一步破壞系統。 如果你在數據不足或質量差的數據之上應用 AI/ML，你可能會在錯誤的方向上推動自動化，因為算法會學習到錯誤的東西。
如果沒有隨著時間的推移與指標、日志和跟蹤數據相關的拓撲數據，AIOps 工具可能無法理解這些不同類型的數據在聚集在一起時之間的相關性。 AIOps 需要拓撲和時間提供的額外上下文，以便準確評估根本原因、確定業務影響、檢測異常并主動確定何時提醒 SRE 和 DevOps 團隊。
| 說明 | |
|---|---|
| 第 4 級：AIOps 的主動可觀測性 | 使用 AIOps 對堆積如山的數據進行分類并確定最重要的模式和有影響力的事件，這樣團隊就可以將時間集中在重要的事情上。 |
| 系統輸入 | 1-3 級 + AI/ML 模型 |
| 系統輸出 | 1-3 級 + 實現快速 MTTR 和防止故障的主動洞察 |
| 你得到什么 | ? 使用 AI/ML 從大量數據中收集和關聯可操作信息，對 IT 環境運營有新見解 ? 在問題影響業務之前突出顯示問題的預測和異常檢測 ? 團隊將精力集中在最具影響力的事件上，從而提高效率并減少工作量 ? 提高了自動根本原因分析、業務影響分析和警報關聯的準確性 ? 事件數據足夠準確，可有效用于自動化 ITSM 和自我修復系統 |
表 6：第 4 級總結
下一步
如今，大多數 AIOps 解決方案都需要大量的配置和培訓時間，但通常會產生不準確的結果，尤其是在未考慮拓撲隨時間變化的情況下。 團隊常常帶著不切實際的期望和不明確的目標來實施它們，然后發現自己很失望。
4 級是目前最終的可觀測性成熟度級別，但隨著 IT 的不斷發展，我們完全期待出現 5 級。
總結
幾十年來，IT 運營團隊一直依靠監控來深入了解其系統的可用性和性能。 但向更先進的 IT 技術和實踐的轉變推動了對監控的更多需求——因此可觀測性得到了發展。
借助跨越多個動態、分布式和模塊化 IT 環境的基礎架構和應用程序，組織需要更深入、更準確地了解這些系統中發生的一切。 可觀測性提供了全面的洞察力，在每個成熟度級別提供清晰的功能。
