現在人們普遍認為，監控只是可觀察性的一個子集。監控顯示你的IT基礎設施和應用出了問題，而可觀察性則幫助你了解原因，通常是通過分析日志、指標和跟蹤。在今天的環境中，需要各種數據流來確定性能問題的 "根本原因"，可觀察性的圣杯，包括可用性數據、性能指標、自定義指標、事件、日志/跟蹤和事件。可觀察性框架是由這些數據源構建的，它允許運營團隊自信地瀏覽這些數據。

可觀察性還可以確定在有或沒有人工干預的情況下，采取什么樣的規定性行動，以應對甚至防止關鍵的業務中斷場景。要達到可觀察性的高級水平，需要監控從反應性到主動性(或預測性)的演變，最后是規范性監控。讓我們討論一下這種演變包括什么。

不是一件簡單的事情

首先，看一下聯合IT運營的現狀，就會發現其中的挑戰。基礎設施和應用程序分散在暫存、預生產和生產環境中，在企業內部和云中，IT運營團隊不斷參與，以確保這些環境始終可用，滿足業務需求。運營團隊必須處理多種工具、團隊和流程。對于實施可觀察性平臺需要多少數據流，以及如何使企業內的業務和IT運營團隊遵循一個框架，在一段時間內改善運營優化，人們常常感到困惑。

為了使監控工作成熟起來，超越指標儀表板，進入這種可觀察的態勢，它通常分三個階段發展。反應性、主動性(預測性)和規定性。讓我們來看看這些是什么。

第一階段：反應性監測。

這些是監測平臺、工具或框架，它們設置性能基線或規范，然后檢測這些閾值是否被突破并發出相應的警報。它們有助于確定所需的優化配置，以防止達到性能閾值。隨著時間的推移，隨著更多的混合基礎設施被調用或部署以支持越來越多的業務服務和擴大的企業范圍，預先定義的基線可能會發生變化。這可能導致糟糕的性能變得正常化，不觸發警報，導致系統完全崩潰。然后，企業期待主動和預測性監測，以提前提醒他們可能表明即將發生事件的性能異常。

第二階段：主動/預測性監控。

盡管這兩個詞聽起來不同，但預測性監測可以被認為是主動監測的一個子集。主動監測使企業能夠查看來自環境的信號，這些信號可能是或可能不是業務服務中斷的原因。這使企業能夠準備補救方案或標準操作程序(SOP)，以克服零優先級事件。實施主動監控的常見方法之一是為 "管理者的管理者 "提供一個統一的用戶界面，運營團隊可以訪問來自多個監控域的所有警報，以了解其系統的 "正常 "行為和 "性能瓶頸 "行為。當某種行為模式與現有的機器學習模式相匹配，表明存在潛在問題時，監控系統就會觸發警報。

預測性監測對市場上較新的技術使用動態閾值，而沒有對它們應該如何執行的第一手經驗。然后，這些工具了解一段時間內的指標行為，并在注意到標準偏差時發出警報，這可能導致最終用戶會注意到的中斷或性能下降。可以根據這些警報采取相應的行動，防止發生影響業務的事件。

第三階段：規范性監測。

這是可觀察性框架的最后階段，監測系統可以從環境中的事件和補救/自動化包中學習，并了解以下情況。

• 哪些警報是最經常發生的，以及針對這些警報從自動化包中執行哪些補救行動?
• 某些被觸發的資源是否屬于同一個數據中心，或者是在多個數據中心看到的相同問題，這可能導致理解錯誤的配置基線。
• 如果一個警報是季節性的，可以在以后的階段忽略，而不執行不必要的自動化。
• 對作為縱向或橫向擴展的一部分而引入的新資源執行哪些補救措施。
• IT運營團隊需要適當的算法來關聯和制定這些方案。這可以是ITOM和ITSM系統對IT運營分析引擎的反饋的組合，以建立規范的模型。

展望未來

監控不是可觀察性，而是它的一個關鍵部分，從反應式監控開始，當預先定義的性能閾值被突破時，它會告訴你。隨著你將更多的基礎設施和應用服務上線，監控需要轉向主動和預測模型，這些模型分析更大的監控數據集，并在服務水平和用戶體驗受到影響之前檢測可能表明潛在問題的異常情況。

然后，可觀察性框架需要分析一系列的數據點，以便在檢測到異常的最初幾分鐘內確定性能問題或中斷場景的最可能的原因，然后在進入作戰室/情況分析電話之前開始努力補救該性能問題。最終的結果是更好的用戶體驗，一個永遠可用的系統，以及改善業務運營。