前言

在 StackState，我們?cè)诒O(jiān)控和可觀測(cè)性領(lǐng)域工作了八年。 在這段時(shí)間里，我們與無數(shù) DevOps 工程師、架構(gòu)師、SRE、IT 運(yùn)營(yíng)負(fù)責(zé)人和 CTO 進(jìn)行了交談，我們一遍又一遍地聽到了同樣的掙扎。

今天的消費(fèi)者已經(jīng)習(xí)慣了始終有效的偉大技術(shù)。 他們對(duì)中斷或性能問題幾乎沒有容忍度。 這些期望促使企業(yè)通過頻繁發(fā)布、更快的響應(yīng)和更高的可靠性來保持競(jìng)爭(zhēng)力。 與此同時(shí)，向基于云的應(yīng)用程序（及其所有不斷變化的功能、微服務(wù)和容器）的轉(zhuǎn)變使 IT 環(huán)境比以往任何時(shí)候都更加復(fù)雜和難以操作和監(jiān)控。

因此，我們?cè)谌蚍秶鷥?nèi)展開的監(jiān)控挑戰(zhàn)中看到了很大的共性，例如客戶描述的這個(gè)豐富多彩的問題：

“當(dāng)基礎(chǔ)設(shè)施、存儲(chǔ)、網(wǎng)絡(luò)設(shè)備或類似的東西出現(xiàn)重大問題時(shí)……每次我們都看同一部電影。監(jiān)控會(huì)變成紅色、紅色、紅色，成千上萬的警報(bào)，沒人知道根本原因是什么。 每個(gè)人都很恐慌——真正的混亂?！?/p>

—— Georg H?llebauer，APA-Tech 的企業(yè)指標(biāo)架構(gòu)師

八年前我親眼目睹了這個(gè)問題，當(dāng)時(shí)我是荷蘭一家大型銀行的兩名顧問團(tuán)隊(duì)的一員，幫助他們提高關(guān)鍵任務(wù)應(yīng)用程序的可靠性。 他們是一家成熟的企業(yè)，針對(duì)復(fù)雜的環(huán)境配備了多種監(jiān)控工具，但他們無法快速找到問題的根源。 由于許多孤立的工具和缺乏統(tǒng)一的 IT 環(huán)境視圖，客戶體驗(yàn)受到直接影響。 當(dāng)出現(xiàn)問題時(shí)，找到并解決核心問題的時(shí)間太長(zhǎng)了。 我們知道我們必須找到更好的方法，而我們?yōu)闈M足這家銀行的需求而構(gòu)建的技術(shù)成為 StackState 的基礎(chǔ)。

自從我們?cè)?2017 年發(fā)布了最初的監(jiān)控成熟度模型以來，很明顯，最初的監(jiān)控工具——它只是在出現(xiàn)問題時(shí)通知 IT 團(tuán)隊(duì)——對(duì)許多其他組織來說也不再足夠了。 今天的工程師需要立即了解問題的優(yōu)先級(jí)和背景：對(duì)客戶體驗(yàn)和業(yè)務(wù)結(jié)果有何影響？ 那么，如果影響很大：它為什么會(huì)崩潰，我們?nèi)绾涡迯?fù)它？

可觀測(cè)性的概念已經(jīng)從監(jiān)控演變?yōu)榛卮疬@些問題。 可觀測(cè)性對(duì)于維持業(yè)務(wù)成功所需的服務(wù)可靠性水平至關(guān)重要。 不幸的是，在監(jiān)控和可觀測(cè)性空間中導(dǎo)航是很困難的，尤其是當(dāng) AIOps 進(jìn)入畫面時(shí)。 許多供應(yīng)商在市場(chǎng)上大放異彩，新的開源項(xiàng)目層出不窮。 很難知道誰真正做了什么，更難知道哪些能力真正重要。

可觀測(cè)性成熟度模型基于對(duì)實(shí)際環(huán)境中實(shí)際問題的廣泛經(jīng)驗(yàn)、與客戶和潛在客戶的討論、對(duì)最新技術(shù)的研究以及與 Gartner 等領(lǐng)先分析公司的對(duì)話。 我們希望它能幫助您在黑暗中發(fā)光。 我們的目標(biāo)不是向您展示您的可觀測(cè)性之旅應(yīng)該是什么樣子的完美模型。 我們知道它不是那樣工作的。 引用一位著名的英國(guó)統(tǒng)計(jì)學(xué)家的話，“所有模型都是錯(cuò)誤的，有些是有用的。”

相反，我們編寫此可觀測(cè)性成熟度模型是為了幫助您確定您在可觀測(cè)性路徑上的位置，了解前方的道路并提供地圖以幫助您找到自己的方式。

愿此模型對(duì)您的旅途有用！

Co-founder and Chief Technology Officer
StackState

簡(jiǎn)介：為什么要使用可觀測(cè)性成熟度模型？

監(jiān)控作為 IT 運(yùn)營(yíng)團(tuán)隊(duì)深入了解其系統(tǒng)的可用性和性能的一種方式已經(jīng)存在了幾十年。 為了滿足市場(chǎng)需求、更快地創(chuàng)新并更好地支持業(yè)務(wù)目標(biāo)，IT 組織需要更深入、更準(zhǔn)確地了解其技術(shù)環(huán)境中正在發(fā)生的事情。 獲得這種洞察力并不容易，因?yàn)楫?dāng)今的基礎(chǔ)設(shè)施和應(yīng)用程序跨越多種技術(shù)，使用多種架構(gòu)，并且本質(zhì)上更加動(dòng)態(tài)、分布式和模塊化。

變化也是 IT 的一種生活方式，研究表明 76% 的問題是由變化引起的。為了在面對(duì)所有這些挑戰(zhàn)時(shí)保持可靠性，公司的監(jiān)控策略必須發(fā)展為可觀測(cè)性。

66% 的 MTTR 用于識(shí)別導(dǎo)致問題的變化

大多數(shù)企業(yè)發(fā)現(xiàn)很難找到正確的監(jiān)控策略來可靠地管理他們的環(huán)境。 超過 65% 的企業(yè)組織擁有 10 多個(gè)監(jiān)控工具，通常作為孤立的解決方案運(yùn)行。這種分離的結(jié)構(gòu)限制了 SRE 和 IT 運(yùn)營(yíng)團(tuán)隊(duì)快速檢測(cè)、診斷和解決性能問題的能力。 出現(xiàn)問題時(shí)，團(tuán)隊(duì)會(huì)嘗試通過組合團(tuán)隊(duì)、流程和工具，或通過手動(dòng)拼湊孤立的數(shù)據(jù)片段來找到根本原因。 這種傳統(tǒng)的監(jiān)控方法非常耗時(shí)，并且無法提供改善業(yè)務(wù)成果所需的洞察力。 故障排除速度太慢，您最重要的面向客戶的系統(tǒng)可能會(huì)停機(jī)數(shù)小時(shí)，從而導(dǎo)致數(shù)百萬美元的收入損失。

向動(dòng)態(tài)云、容器、微服務(wù)和無服務(wù)器架構(gòu)的轉(zhuǎn)變，加上維護(hù)混合環(huán)境和遺留記錄系統(tǒng)的需要，進(jìn)一步加劇了對(duì)更高級(jí)功能的需求。

云和容器遷移推動(dòng)了對(duì)更高可觀測(cè)性成熟度的需求

可觀測(cè)性實(shí)踐已經(jīng)發(fā)展以滿足這些需求，將監(jiān)控方面的進(jìn)步與更全面的方法相結(jié)合，提供更深入的洞察力和對(duì)跨技術(shù)環(huán)境正在發(fā)生的事情的更準(zhǔn)確的理解。 可觀測(cè)性成熟度模型定義了可觀測(cè)性演變的四個(gè)不同級(jí)別，如下頁表 1 中所述。

表 1：定義可觀測(cè)性成熟度級(jí)別

每個(gè)級(jí)別的可觀測(cè)性都建立在先前級(jí)別建立的基礎(chǔ)之上，以增加捕獲、跟蹤和分析數(shù)據(jù)的能力。 新功能支持在每個(gè)階段進(jìn)行更深入的觀察，從而提高 IT 可靠性和客戶滿意度，如下面的圖 1 所示。 雖然您可以通過增強(qiáng)流程在某個(gè)級(jí)別內(nèi)略微改進(jìn)結(jié)果，但大多數(shù)團(tuán)隊(duì)需要收集新類型的數(shù)據(jù)以推進(jìn)到下一個(gè)成熟度級(jí)別并實(shí)現(xiàn)更大的收益。

圖 1：可觀測(cè)性成熟度及其對(duì) IT 可靠性的影響

可觀測(cè)性成熟度模型基于與跨行業(yè)企業(yè)的研究和對(duì)話，并已得到其他從業(yè)者、分析師和思想領(lǐng)袖的驗(yàn)證。 它旨在幫助您：

? 了解不同類型的數(shù)據(jù)以及監(jiān)控和可觀測(cè)性實(shí)踐如何幫助您的組織收集可操作的信息。
? 了解監(jiān)控、可觀測(cè)性和AIOps 之間的區(qū)別。
? 評(píng)估您的組織當(dāng)前的成熟度水平。
? 引導(dǎo)您的團(tuán)隊(duì)達(dá)到更高的成熟度。

使用此模型了解您可以采取哪些清晰的步驟來提高組織中的可觀測(cè)性，以便您最終可以向客戶交付更可靠和更具彈性的應(yīng)用程序。

第一級(jí)：監(jiān)控

目標(biāo)：確保各個(gè)組件按預(yù)期工作。

第一級(jí)，監(jiān)控，對(duì) IT 來說并不陌生。 監(jiān)視器跟蹤單個(gè)系統(tǒng)組件的特定參數(shù)，以確保它保持在可接受的范圍內(nèi)。 如果該值超出范圍，監(jiān)視器將觸發(fā)一個(gè)操作，例如警報(bào)、狀態(tài)更改、通知或警告。

傳統(tǒng)監(jiān)控通常包括應(yīng)用程序性能監(jiān)控 (APM)、基礎(chǔ)設(shè)施監(jiān)控、API 監(jiān)控、網(wǎng)絡(luò)監(jiān)控和各種其他以域?yàn)橹行牡墓ぞ撸美恰爱?dāng)某些事情運(yùn)行不滿意時(shí)通知我”。 您可以根據(jù)交通燈顏色來考慮監(jiān)控：

• 組件可用且健康（綠色）
• 組件存在風(fēng)險(xiǎn)（橙色或黃色）
• 組件損壞（紅色）

監(jiān)控著眼于預(yù)定義的值集和預(yù)定義的故障模式集。 它關(guān)注基本的組件級(jí)參數(shù)，例如可用性、性能和容量，并生成報(bào)告監(jiān)視值狀態(tài)的事件。

事件是 IT 環(huán)境中值得注意的變化。 盡管事件可能純粹是提供信息，但它們通常描述需要采取行動(dòng)的關(guān)鍵事件。 事件可能會(huì)觸發(fā)通過各種渠道到達(dá)的警報(bào)或通知，例如電子郵件、聊天、移動(dòng)應(yīng)用程序或事件管理系統(tǒng)。

作為實(shí)現(xiàn)可觀測(cè)性的第一步，實(shí)施監(jiān)控以獲得對(duì)各個(gè)組件的健康和狀態(tài)的基本洞察，并在出現(xiàn)問題時(shí)收到通知。 下面的表 2 概述了級(jí)別 1 的關(guān)鍵功能。

表 2：第 1 級(jí)總結(jié)

下一步：可觀測(cè)性

監(jiān)控使您對(duì)整體環(huán)境狀態(tài)的了解有限。 它向您顯示單個(gè)組件的運(yùn)行狀況，但通常沒有關(guān)于全局的信息。 它會(huì)告訴您出現(xiàn)問題，但不會(huì)告訴您原因、聯(lián)系誰，也不會(huì)告訴您原始問題出現(xiàn)的時(shí)間和地點(diǎn)。

設(shè)置和維護(hù)監(jiān)控檢查和通知渠道需要大量手動(dòng)工作。 在第 1 級(jí)，您還需要手動(dòng)進(jìn)行根本原因分析和影響分析，并且您的數(shù)據(jù)集有限。 調(diào)查問題的根源需要時(shí)間。 此外，單個(gè)問題可能會(huì)導(dǎo)致來自多個(gè)組件的警報(bào)風(fēng)暴，導(dǎo)致進(jìn)一步的混亂和延遲查明根本原因。

雖然監(jiān)控可以檢測(cè)到有限數(shù)量的已知類型的故障或“已知的未知數(shù)”，但第 2 級(jí)可觀測(cè)性可以幫助您發(fā)現(xiàn)未知和意外的故障模式或“未知的未知數(shù)”。 當(dāng)您從級(jí)別 1 升級(jí)到級(jí)別 2 時(shí)，您將獲得更深入的信息，從而更好地了解服務(wù)的可用性、性能和行為。

第二級(jí)：可觀測(cè)性

目標(biāo)：確定系統(tǒng)不工作的原因。
為了讓當(dāng)今復(fù)雜和動(dòng)態(tài)的 IT 系統(tǒng)可靠地運(yùn)行，您不僅需要知道什么在工作（監(jiān)控），還需要了解它為什么不工作（可觀測(cè)性）。

傳統(tǒng)監(jiān)控跟蹤組件或系統(tǒng)的基本健康狀況。 隨著時(shí)間的推移，可觀測(cè)性自然演變，以提供對(duì)系統(tǒng)行為的更深入洞察。 當(dāng)出現(xiàn)問題并且您的團(tuán)隊(duì)收到警報(bào)時(shí)，您需要快速弄清楚，“發(fā)生了什么事？ 我們?cè)谀睦?、什么時(shí)候、為什么以及給誰打電話？” 可觀測(cè)性數(shù)據(jù)可以幫助您回答這些問題。 在其完全成熟（第 4 級(jí)）時(shí)，可觀測(cè)性在適當(dāng)?shù)纳舷挛闹刑峁┠枰乃袛?shù)據(jù)，以自動(dòng)檢測(cè)和修復(fù)問題，甚至主動(dòng)識(shí)別和預(yù)防問題。

當(dāng)彈出警報(bào)時(shí)，您希望了解系統(tǒng)的狀態(tài)以找到問題的根源。 在第 2 級(jí)，可觀測(cè)性通常通過關(guān)注三種關(guān)鍵類型的遙測(cè)數(shù)據(jù)來提供系統(tǒng)洞察力：指標(biāo)、日志和跟蹤。 可觀測(cè)性的這三大支柱是從 IT 組件（例如微服務(wù)、應(yīng)用程序和數(shù)據(jù)庫）中收集的，以提供對(duì)系統(tǒng)的整體視角。 系統(tǒng)的行為。 每個(gè)支柱提供不同類型的信息，如下表 3 所示。

表 3：可觀測(cè)性的三大支柱

這三大支柱以及事件和警報(bào)通常繪制在儀表板上，因此團(tuán)隊(duì)可以輕松跟蹤重要活動(dòng)。 一些可觀測(cè)性工具提供開箱即用的儀表板，將這些不同類型的數(shù)據(jù)匯集在一個(gè)屏幕上，并允許您深入研究它們以進(jìn)行進(jìn)一步調(diào)查。

2 級(jí)數(shù)據(jù)比 1 級(jí)數(shù)據(jù)具有更大的廣度和深度，并且它通常涉及將整個(gè)環(huán)境中的一些數(shù)據(jù)整合到單個(gè)視圖中。 如果您想要獲得更多見解，您可能需要構(gòu)建額外的儀表板，尤其是當(dāng)您的環(huán)境有多個(gè)域并且您正在使用多個(gè)監(jiān)控工具時(shí)。

表 4：2 級(jí)總結(jié)

那么挑戰(zhàn)就變成了如何解決來自太多儀表板的信息。 在第 2 級(jí)，您可以通過手動(dòng)關(guān)聯(lián)數(shù)據(jù)來推斷事件的可疑原因，但這種方法通常涉及跨系統(tǒng)的復(fù)雜手動(dòng)查詢。

在第 2 級(jí)，團(tuán)隊(duì)尚未開發(fā)出一種自動(dòng)化方法來統(tǒng)一和關(guān)聯(lián)來自各種工具和領(lǐng)域的孤立數(shù)據(jù)，因此查明問題的根本原因仍然是勞動(dòng)密集型和耗時(shí)的。 因此，MTTD 和 MTTR 高于它們應(yīng)有的水平，與較高成熟度水平相比，客戶受到的不利影響更大，收入損失更多。

下一步：因果可觀測(cè)性

可觀測(cè)性會(huì)產(chǎn)生大量數(shù)據(jù)，并且整理出有意義的信息可能很困難。

在第 2 級(jí)，您的團(tuán)隊(duì)可能面臨數(shù)據(jù)孤島和數(shù)據(jù)量的挑戰(zhàn)，這會(huì)導(dǎo)致跨域和跨團(tuán)隊(duì)故障排除效率低下。

當(dāng)出現(xiàn)問題時(shí)，因?yàn)闆]有人知道問題出在哪里，所以涉及的人太多，導(dǎo)致事件乒乓球和推諉游戲。 您可能需要構(gòu)建臨時(shí)解決方案來查詢多個(gè)可觀測(cè)性孤島以解決單個(gè)問題。 創(chuàng)建這些查詢需要從業(yè)者具備開發(fā)技能、數(shù)據(jù)結(jié)構(gòu)知識(shí)和對(duì)系統(tǒng)架構(gòu)的理解。

此外，第 2 級(jí)中典型的以遙測(cè)為中心的孤立視圖通常需要大量手動(dòng)工作才能提取可操作的見解。 設(shè)置高效的儀表板可能需要相當(dāng)長(zhǎng)的時(shí)間，并且需要持續(xù)維護(hù)。 根本原因分析、影響分析和警報(bào)降噪對(duì)于維護(hù)可靠和有彈性的堆棧很重要，但這些活動(dòng)在這個(gè)級(jí)別上具有挑戰(zhàn)性。

注意：團(tuán)隊(duì)越來越多地采用 OpenTelemetry 標(biāo)準(zhǔn)來促進(jìn)指標(biāo)、日志和跟蹤的捕獲。 OpenTelemetry 非常有助于有效地收集這些類型的數(shù)據(jù)，但它并不是為了彌合孤島、為數(shù)據(jù)創(chuàng)建更好的上下文或分析數(shù)據(jù)而設(shè)計(jì)的。

為了進(jìn)入第 3 級(jí)并了解您的可觀測(cè)性數(shù)據(jù)是如何相關(guān)的，您需要為 IT 環(huán)境中的數(shù)據(jù)孤島中的事件、日志、指標(biāo)和跟蹤提供上下文。 在第 3 級(jí)，因果可觀測(cè)性，您可以獲得業(yè)務(wù)流程、應(yīng)用程序和基礎(chǔ)架構(gòu)的精確拓?fù)鋱D，并且您可以跟蹤它是如何隨時(shí)間變化的。 當(dāng)出現(xiàn)問題時(shí)，您可以結(jié)合自動(dòng)化使用此上下文數(shù)據(jù)來快速確定問題的原因，而無需手動(dòng)處理不相關(guān)的數(shù)據(jù)孤島。

級(jí)別 3：因果可觀測(cè)性

目標(biāo)：找到事件的原因并確定其對(duì)整個(gè)系統(tǒng)的影響。

毫不奇怪，大多數(shù)故障是由系統(tǒng)中某處的更改引起的，例如新代碼部署、配置更改、自動(dòng)縮放活動(dòng)或自動(dòng)修復(fù)事件。 當(dāng)您調(diào)查事件的根本原因時(shí)，最好的起點(diǎn)是找出發(fā)生了什么變化。

要了解是什么變化導(dǎo)致了問題以及什么影響在您的堆棧中傳播，您需要能夠看到堆棧組件之間的關(guān)系如何隨時(shí)間變化：

? 問題開始時(shí)堆棧是什么樣子的？
? 哪些組件受到影響？
? 所有警報(bào)如何關(guān)聯(lián)？

我們將此級(jí)別的洞察力稱為因果可觀測(cè)性，它可以讓您跟蹤堆棧中的因果關(guān)系，即因果可觀測(cè)性——它建立在第 1 級(jí)和第 2 級(jí)奠定的基礎(chǔ)之上。

“從拓?fù)渲械臄?shù)據(jù)導(dǎo)出模式將建立相關(guān)性并說明隱藏的依賴關(guān)系。 使用拓?fù)渥鳛橐蚬P(guān)系確定的一部分可以大大提高其準(zhǔn)確性和有效性。”

—— Gartner? AIOps 平臺(tái)市場(chǎng)指南，2022 年 5 月，Pankaj Prasad、Padraig Byrne、Gregg Siegfried

拓?fù)涫且蚬捎^測(cè)性的第一個(gè)必要維度。 拓?fù)涫?IT 環(huán)境中所有組件的映射，它跨越所有層，從網(wǎng)絡(luò)到應(yīng)用程序再到存儲(chǔ)，顯示一切是如何相關(guān)的。 拓?fù)浣Y(jié)合了組件之間的邏輯依賴性、物理接近性和其他關(guān)系，以提供人類可讀的可視化和可操作的關(guān)系數(shù)據(jù)。

拓?fù)涿枋隽谁h(huán)境中離散組件之間的一組關(guān)系和依賴關(guān)系，例如，業(yè)務(wù)服務(wù)、微服務(wù)、負(fù)載平衡器、容器和數(shù)據(jù)庫。

在當(dāng)今的現(xiàn)代環(huán)境中，隨著新代碼不斷被推入生產(chǎn)環(huán)境以及底層基礎(chǔ)設(shè)施的快速變化，拓?fù)浣Y(jié)構(gòu)也在迅速發(fā)展。 管理這些動(dòng)態(tài)環(huán)境需要能夠跟蹤拓?fù)潆S時(shí)間的變化（時(shí)間序列拓?fù)洌?，為堆棧中發(fā)生的活動(dòng)提供歷史和實(shí)時(shí)上下文。

現(xiàn)代環(huán)境由如此多的動(dòng)態(tài)層、微服務(wù)、無服務(wù)器應(yīng)用程序和網(wǎng)絡(luò)技術(shù)組成，因此向您的可觀測(cè)性組合添加最新拓?fù)鋵?duì)于區(qū)分因果關(guān)系至關(guān)重要。 拓?fù)錇閿?shù)千個(gè)未連接的數(shù)據(jù)流提供錨點(diǎn)
賦予它們結(jié)構(gòu)，使以前不可見的連接可見。 拓?fù)淇梢暬屇梢栽谌珬；顒?dòng)的上下文中查看來自網(wǎng)絡(luò)、基礎(chǔ)設(shè)施、應(yīng)用程序和其他領(lǐng)域的遙測(cè)數(shù)據(jù)； 它還為您提供了重要的背景信息，讓您了解發(fā)生故障時(shí)您的業(yè)務(wù)會(huì)受到怎樣的影響。

圖 2：因果可觀測(cè)性需要整合您環(huán)境中所有來源的拓?fù)湫畔ⅰ?/div>

然而，對(duì)于大多數(shù)公司而言，僅添加拓?fù)洳蛔阋蕴峁┮蚬捎^測(cè)性。 尤其是在當(dāng)今具有微服務(wù)、頻繁部署、不斷變化的云資源和上下旋轉(zhuǎn)的容器的動(dòng)態(tài)現(xiàn)代環(huán)境中，拓?fù)浣Y(jié)構(gòu)變化很快。 您的堆?，F(xiàn)在看起來可能不是問題剛開始時(shí)的樣子。 因此，第二個(gè)維度對(duì)于創(chuàng)建因果可觀測(cè)性的基礎(chǔ)是必要的：時(shí)間。

圖 3：捕獲時(shí)間序列拓?fù)湟愿櫠褩８牟⒖焖倥懦驹颉?/div>

最后，要了解現(xiàn)代 IT 環(huán)境的動(dòng)態(tài)行為并獲得實(shí)現(xiàn)因果可觀測(cè)性所需的上下文，您需要將環(huán)境的拓?fù)渑c其關(guān)聯(lián)的指標(biāo)、日志、事件和跟蹤數(shù)據(jù)關(guān)聯(lián)起來。

圖 4：隨著時(shí)間的推移捕獲拓?fù)洳⑵渑c指標(biāo)、日志、事件和跟蹤相關(guān)聯(lián)以跟蹤堆棧中的變化。 稍后，當(dāng)問題出現(xiàn)時(shí)，您可以及時(shí)回到問題開始的確切時(shí)刻，看看是什么變化導(dǎo)致了它。

在第 3 級(jí)，與遙測(cè)數(shù)據(jù)相關(guān)的拓?fù)浜蜁r(shí)間的其他維度向您顯示跨不同層、數(shù)據(jù)孤島、團(tuán)隊(duì)和技術(shù)的任何更改或故障的原因和影響——顯著縮短解決時(shí)間和業(yè)務(wù)成果。 您還具備開始自動(dòng)化根本原因分析、業(yè)務(wù)影響分析和警報(bào)關(guān)聯(lián)的基礎(chǔ)。 更高級(jí)的 AIOps 也需要這種更深層次的數(shù)據(jù)，正如您將在第 4 級(jí)中了解到的那樣。

建立因果可觀測(cè)性和 AIOps 基礎(chǔ)的 4 個(gè)關(guān)鍵步驟

1. 整合：首先，您需要確保整合了來自整個(gè)企業(yè)的數(shù)據(jù)堆放在一個(gè)地方，這樣您就可以看到完整的視圖。
2. 收集拓?fù)鋽?shù)據(jù)：接下來，您需要構(gòu)建環(huán)境的拓?fù)鋱D，這是堆棧中組件的映射，顯示它們?nèi)绾蜗嗷リP(guān)聯(lián)。 可視化拓?fù)淇梢钥焖倩卮鹨韵聠栴}：“哪個(gè)組件依賴于其他組件？ 如果一項(xiàng)服務(wù)失敗，還有什么會(huì)受到影響？”
3. 關(guān)聯(lián)：您需要關(guān)聯(lián)所有這些統(tǒng)一的數(shù)據(jù)，這樣您的整個(gè) IT 環(huán)境就可以作為一個(gè)整體進(jìn)行分析，甚至可以跨孤島進(jìn)行分析。 拓?fù)渲械拿總€(gè)組件都需要與其關(guān)聯(lián)的指標(biāo)、日志、事件和跟蹤數(shù)據(jù)相關(guān)聯(lián)。
4. 隨著時(shí)間的推移跟蹤一切：最后，如果您想了解一個(gè)組件中的更改如何在您的堆棧中傳播，您需要將您的拓?fù)鋽?shù)據(jù)與隨時(shí)間變化的指標(biāo)、日志和跟蹤數(shù)據(jù)相關(guān)聯(lián)。

	說明
級(jí)別 3：因果可觀測(cè)性	通過單個(gè)拓?fù)鋵⑦b測(cè)數(shù)據(jù)（指標(biāo)、跟蹤、事件、日志）關(guān)聯(lián)起來。 隨著時(shí)間的推移關(guān)聯(lián)所有數(shù)據(jù)以跟蹤變化在您的堆棧中傳播。
系統(tǒng)輸入	級(jí)別 1 和 2 + 時(shí)間序列拓?fù)浼?jí)別
系統(tǒng)輸出	1 和 2 + 相關(guān)拓?fù)?、遙測(cè)和時(shí)間數(shù)據(jù)顯示在上下文可視化中，顯示堆棧中更改的影響
你得到什么	? 通過統(tǒng)一時(shí)間序列拓?fù)渲械墓铝?shù)據(jù)，獲得統(tǒng)一、清晰、相關(guān)的環(huán)境狀態(tài)上下文視圖 ? 通過拓?fù)淇梢暬头治隽私庖蚬P(guān)系，顯著加快根本原因識(shí)別和解決時(shí)間 ? 基本自動(dòng)化調(diào)查的基礎(chǔ)，例如根本原因分析、業(yè)務(wù)影響分析和警報(bào)關(guān)聯(lián) ? 自動(dòng)將與同一根本原因相關(guān)的警報(bào)集中在一起，從而減少噪音和干擾所需的上下文 ? 能夠可視化網(wǎng)絡(luò)、基礎(chǔ)設(shè)施和應(yīng)用程序事件對(duì)業(yè)務(wù)服務(wù)和客戶的影響

表 5：第 3 級(jí)總結(jié)

下一步：使用 AIOps 主動(dòng)觀察

如上所述，Gartner 指出拓?fù)淇梢源蟠筇岣邷?zhǔn)確性和有效性

因果決定。 第 3 級(jí)是向前邁出的一大步，但統(tǒng)一來自不同孤島的數(shù)據(jù)在數(shù)據(jù)規(guī)范化、相關(guān)性和質(zhì)量方面提出了挑戰(zhàn)，這些挑戰(zhàn)可能需要新功能甚至組織變革來解決。 此外，很難大規(guī)模收集和操作高質(zhì)量的拓?fù)鋽?shù)據(jù)，尤其是在不太現(xiàn)代化的環(huán)境中。

每個(gè)拓?fù)湓炊夹枰粩嗔魅胫魍負(fù)洌虼四枰_保您的系統(tǒng)能夠隨時(shí)間存儲(chǔ)拓?fù)洹?隨著時(shí)間的推移存儲(chǔ)與遙測(cè)數(shù)據(jù)相關(guān)的拓?fù)浣Y(jié)構(gòu)提出了更大的挑戰(zhàn)。

“隨著十幾個(gè)或更多不同領(lǐng)域的數(shù)據(jù)量達(dá)到或超過每分鐘千兆字節(jié)，人工手動(dòng)分析數(shù)據(jù)以滿足運(yùn)營(yíng)預(yù)期已不再可能，更不實(shí)用?！?/p>

—— Gartner? AIOps 平臺(tái)市場(chǎng)指南，2022 年 5 月，Pankaj Prasad、Padraig Byrne、Gregg Siegfried

在制定實(shí)施計(jì)劃時(shí)考慮這些問題。 另請(qǐng)記住，第 3 級(jí)數(shù)據(jù)的速度、數(shù)量和種類通常如此之大，以至于要實(shí)現(xiàn)您的總體可靠性目標(biāo)，可能需要 AI 來幫助將信號(hào)與噪聲分開。 當(dāng)您進(jìn)入第 4 級(jí)時(shí)，您可以在第 1-3 級(jí)之上添加用于 IT 運(yùn)營(yíng)的人工智能 (AIOps)，以獲得更準(zhǔn)確的洞察力。

第 4 級(jí)：AIOps 的主動(dòng)可觀測(cè)性

目標(biāo)：分析大量數(shù)據(jù)，自動(dòng)響應(yīng)事件并防止異常成為問題。

第 4 級(jí)，使用 AIOps 的主動(dòng)可觀測(cè)性，是最高級(jí)的可觀測(cè)性。 在此階段，用于 IT 運(yùn)營(yíng)的人工智能 (AIOps) 被添加到組合中。 在監(jiān)控和可觀測(cè)性的背景下，AIOps 是關(guān)于應(yīng)用人工智能和機(jī)器學(xué)習(xí) (ML) 對(duì)堆積如山的數(shù)據(jù)進(jìn)行分類，以尋找模式

? 推動(dòng)更好的回應(yīng)
? 盡快
? 由人和自動(dòng)化系統(tǒng)共同完成。

在 Gartner 2022 年 5 月由 Pankaj Prasad、Padraig Byrne 和 Gregg Siegried 撰寫的“AIOps 平臺(tái)市場(chǎng)指南”中，Gartner 通過以下方式定義了 AIOps 平臺(tái)的特征：

“AIOps 平臺(tái)分析遙測(cè)和事件，并確定有意義的模式，這些模式提供了支持主動(dòng)響應(yīng)的見解。 AIOps平臺(tái)有五個(gè)特點(diǎn)：
1.跨域數(shù)據(jù)攝取和分析

2. 資產(chǎn)關(guān)系和依賴的隱式和顯式來源的拓?fù)浣M裝
3. 與事件關(guān)聯(lián)的相關(guān)或冗余事件之間的關(guān)聯(lián)
4. 模式識(shí)別以檢測(cè)事件、其主要指標(biāo)或可能的根本原因
5. 可能補(bǔ)救協(xié)會(huì)”

我們對(duì) AIOps 的看法與 Gartner 相同。 AIOps 建立在該成熟度模型中先前級(jí)別的核心功能之上——例如收集和操作數(shù)據(jù)、拓?fù)浣M裝和數(shù)據(jù)關(guān)聯(lián)——并添加了模式識(shí)別、異常檢測(cè)和更準(zhǔn)確的問題修復(fù)建議。 因果可觀測(cè)性是一個(gè)必要的基礎(chǔ)：時(shí)間序列拓?fù)涮峁┝艘粋€(gè)必要的框架。

AIOps 可以幫助團(tuán)隊(duì)更快地發(fā)現(xiàn)問題，甚至可以完全預(yù)防問題。 AI/ML 算法尋找警告、警報(bào)和故障之前的模式變化，幫助團(tuán)隊(duì)了解服務(wù)或組件何時(shí)開始偏離正常行為，并在出現(xiàn)故障之前解決問題。

“發(fā)現(xiàn)異常很容易，因?yàn)樗鼈円恢倍荚诎l(fā)生。 當(dāng)您每天收集十億個(gè)事件時(shí)，每?jī)煞昼娋蜁?huì)發(fā)生一百萬分之一的事件。 可觀測(cè)性工具的關(guān)鍵是發(fā)現(xiàn)與手頭問題相關(guān)的異常，然后從可能相關(guān)的日志文件/指標(biāo)中鏈接其他信息。 通過在上下文中顯示相關(guān)信息，操作員可以更快地找出問題的潛在根本原因?！?/p>

– Gartner?“Innovation Insight for Observability”，2022 年 3 月，Padraig Byrne 和 Josh Chessman

一盎司的預(yù)防勝過一磅的治療。 有什么比完全阻止事件發(fā)生更好的提高可靠性的方法呢？

然而，異常經(jīng)常發(fā)生。 它們并不一定意味著會(huì)發(fā)生問題，也不意味著補(bǔ)救應(yīng)該是高優(yōu)先級(jí)。 AIOps 有助于確定哪些異常需要注意，哪些可以忽略。

AIOps 的另一個(gè)可觀測(cè)性目標(biāo)是通過 IT 服務(wù)管理 (ITSM) 和自我修復(fù)系統(tǒng)推動(dòng)自動(dòng)修復(fù)。 例如，如果這些系統(tǒng)接收到不正確的根本原因輸入，它們可以自我糾正錯(cuò)誤的問題并導(dǎo)致更大的問題。 AIOps 提供更準(zhǔn)確的輸入，從而提高其有效性。

在第 4 級(jí)，您應(yīng)該注意到更高效和無事故的 IT 運(yùn)營(yíng)，提供更好的客戶體驗(yàn)。 為實(shí)現(xiàn)這些目標(biāo)，設(shè)置 AIOps 以超越孤島并攝取從整個(gè)環(huán)境中收集的數(shù)據(jù)。 AI/ML 模型應(yīng)該分析我們?cè)谥凹?jí)別討論的所有可觀測(cè)性數(shù)據(jù)類型：事件、指標(biāo)、日志、跟蹤、更改和拓?fù)?，所有這些都隨著時(shí)間的推移而關(guān)聯(lián)。

注意事項(xiàng)：不要跳過第 3 級(jí)

AIOps 的主動(dòng)可觀測(cè)性是確保 IT 系統(tǒng)可靠運(yùn)行的最佳方式，但直接進(jìn)入第 4 級(jí)并跳過第 3 級(jí)中的因果可觀測(cè)性步驟（數(shù)據(jù)整合、拓?fù)洹⑺袛?shù)據(jù)流隨時(shí)間的關(guān)聯(lián)）是錯(cuò)誤的 ).

此可觀測(cè)性成熟度模型中的每個(gè)級(jí)別都建立在先前級(jí)別建立的能力之上，但擁有完整的基礎(chǔ)對(duì)于第 4 級(jí)的成功最為重要。如果您在沒有全面數(shù)據(jù)基礎(chǔ)的情況下應(yīng)用 AI/ML，您實(shí)際上可能會(huì)造成損害。 例如，假設(shè)您在自動(dòng)自我修復(fù)系統(tǒng)的前端使用 AI/ML。 如果算法確定的根本原因不正確，則自我修復(fù)系統(tǒng)會(huì)嘗試糾正錯(cuò)誤的事情，并可能進(jìn)一步破壞系統(tǒng)。 如果你在數(shù)據(jù)不足或質(zhì)量差的數(shù)據(jù)之上應(yīng)用 AI/ML，你可能會(huì)在錯(cuò)誤的方向上推動(dòng)自動(dòng)化，因?yàn)樗惴〞?huì)學(xué)習(xí)到錯(cuò)誤的東西。

如果沒有隨著時(shí)間的推移與指標(biāo)、日志和跟蹤數(shù)據(jù)相關(guān)的拓?fù)鋽?shù)據(jù)，AIOps 工具可能無法理解這些不同類型的數(shù)據(jù)在聚集在一起時(shí)之間的相關(guān)性。 AIOps 需要拓?fù)浜蜁r(shí)間提供的額外上下文，以便準(zhǔn)確評(píng)估根本原因、確定業(yè)務(wù)影響、檢測(cè)異常并主動(dòng)確定何時(shí)提醒 SRE 和 DevOps 團(tuán)隊(duì)。

	說明
第 4 級(jí)：AIOps 的主動(dòng)可觀測(cè)性	使用 AIOps 對(duì)堆積如山的數(shù)據(jù)進(jìn)行分類并確定最重要的模式和有影響力的事件，這樣團(tuán)隊(duì)就可以將時(shí)間集中在重要的事情上。
系統(tǒng)輸入	1-3 級(jí) + AI/ML 模型
系統(tǒng)輸出	1-3 級(jí) + 實(shí)現(xiàn)快速 MTTR 和防止故障的主動(dòng)洞察
你得到什么	? 使用 AI/ML 從大量數(shù)據(jù)中收集和關(guān)聯(lián)可操作信息，對(duì) IT 環(huán)境運(yùn)營(yíng)有新見解 ? 在問題影響業(yè)務(wù)之前突出顯示問題的預(yù)測(cè)和異常檢測(cè) ? 團(tuán)隊(duì)將精力集中在最具影響力的事件上，從而提高效率并減少工作量 ? 提高了自動(dòng)根本原因分析、業(yè)務(wù)影響分析和警報(bào)關(guān)聯(lián)的準(zhǔn)確性 ? 事件數(shù)據(jù)足夠準(zhǔn)確，可有效用于自動(dòng)化 ITSM 和自我修復(fù)系統(tǒng)

表 6：第 4 級(jí)總結(jié)

下一步

如今，大多數(shù) AIOps 解決方案都需要大量的配置和培訓(xùn)時(shí)間，但通常會(huì)產(chǎn)生不準(zhǔn)確的結(jié)果，尤其是在未考慮拓?fù)潆S時(shí)間變化的情況下。 團(tuán)隊(duì)常常帶著不切實(shí)際的期望和不明確的目標(biāo)來實(shí)施它們，然后發(fā)現(xiàn)自己很失望。

4 級(jí)是目前最終的可觀測(cè)性成熟度級(jí)別，但隨著 IT 的不斷發(fā)展，我們完全期待出現(xiàn) 5 級(jí)。

總結(jié)

幾十年來，IT 運(yùn)營(yíng)團(tuán)隊(duì)一直依靠監(jiān)控來深入了解其系統(tǒng)的可用性和性能。 但向更先進(jìn)的 IT 技術(shù)和實(shí)踐的轉(zhuǎn)變推動(dòng)了對(duì)監(jiān)控的更多需求——因此可觀測(cè)性得到了發(fā)展。

借助跨越多個(gè)動(dòng)態(tài)、分布式和模塊化 IT 環(huán)境的基礎(chǔ)架構(gòu)和應(yīng)用程序，組織需要更深入、更準(zhǔn)確地了解這些系統(tǒng)中發(fā)生的一切。 可觀測(cè)性提供了全面的洞察力，在每個(gè)成熟度級(jí)別提供清晰的功能。