日志，指標和分布式鏈路追蹤這三個可觀測性的傳統支柱，已經是過時的，過于關注數據采集和底層數據格式，而不去關注結果（我們建設可觀測性的初心和目標），這個做法實在是滑天下之大稽。by Martin Mao

Gartner 把“可觀測性”定義為“監控”的巨大革新，可觀測性提供了數字化業務應用、創新速度、客戶體驗提升方面的洞察能力。如今，DevOps 運動和云原生架構使得企業數字化業務變得更具競爭力，這需要更牛逼的可觀測性體系的支持。

在 DevOps 出現之前，研發工程師很少需要考慮如何運維他們構建的系統。現在，研發工程師需要考慮構建更易于觀測的系統。為了更好的理解可觀測性對結果的影響，工程師應該考慮以下三個關鍵問題：

• 1.當系統出故障時，如何才能讓我盡快收到通知？是在用戶/客戶體驗受損之前嗎？
• 2.如何才能簡單、快速地揪出故障點，圈定影響范圍？
• 3.如何才能找到直接原因并快速止損？

無論使用什么采集方法和工具，可觀測性體系最應該著重建設的，就是回答以上三個問題的能力。

可觀測性不是什么

如今，有很多人將可觀測性定義為一組數據類型的集合——即三個支柱：日志、指標和分布式鏈路追蹤。對于落地可觀測性而言，這種孤立的方法過于關注數據采集和底層數據格式，反而忽略了最終結果（我們建設可觀測性的初心和目標）。

簡單的采集系統中這三種數據并不能保證有更好的結果。反而，很多公司發現：可觀測性數據量和這些數據衍生的價值之間關聯甚微，并非可觀測性數據量越大產生的價值就越大。

可觀測性的3個階段

我們不是第一個對三支柱提出異議的人。像Charity Majors(可觀測性具備多方面定義) 和Ben Sigelman(揭穿“可觀測性的三支柱”神話) 所提出的大部分批判我們也是認同的。我們開發了一種落地可觀測性的新方法，注重結果而非注重輸入，替代可觀測性的三支柱，我們稱之為“三階段”方法。“三階段”重點關注如何實現積極的可觀測性結果，以及如何讓團隊一步一步達成可觀測性目標。

日志，指標和分布式鏈路追蹤這三個可觀測性的傳統支柱，已經是過時的，過于關注數據采集和底層數據格式，而不去關注結果（我們建設可觀測性的初心和目標）。

每個階段的重點都是為了盡快地降低對客戶的影響或修復故障（即：止損）。止損是拯救客戶體驗和恢復服務 Service Level 的動作。在每個階段，工程師都在尋找足夠的信息來止損，即使他們尚未定位到根因。

譯者注：做過 SRE 的兄弟肯定清楚，大部分情況下，『止損』只需要知道直接原因就夠了，不需要知道根因，根因可以在復盤階段再去梳理。舉個例子，某個故障是變更引起的，變更本身就是直接原因，止損手段就是回滾，根本原因可能是這次變更引入的代碼Bug，但具體是什么Bug在止損階段不需要知道。

第一階段：定故障

知道故障正在發生，有時就可以止損了（不需要更多信息）。比如，你升級了某個服務，然后，這個服務告警了，想都不用想，回滾這個變更就是最快的止損手段，不需要先去確認故障影響面、故障根因。變更是萬惡之源，生產事故有一大半都是變更引起的，當你在做變更的時候，時刻掌握服務的健康狀況就異常關鍵。

成功的關鍵：

• 快速報警：縮短問題發生和發出通知之間的時間。
• 將通知范圍限定在需要采取行動的團隊內：從一開始就限定問題的范圍，并將其指派給相關的團隊。
• 提高降噪比：確保每一個警報都有對應的操作預案。
• 自動化告警配置：自動化或模板化的告警配置可以幫助工程師無需投入巨大精力來完成復雜配置就可以收到警報。

工具和數據：

• 告警
• 指標（原生指標以及從日志和鏈路追蹤生成的指標）

第二階段：定邊界

了解故障范圍有助于止損。例如，如果你確認只有一個實驗組的客戶影響，則關閉該實驗特性可能就會解決問題。

為了幫助工程師做故障定界，需要把告警快速置于上下文環境中來分析，了解有多少客戶受影響、有多少系統受影響，以及影響程度如何。好的可觀測性系統，以數據驅動工程師的排查過程，將焦點放在場景化數據上以診斷故障。

成功的關鍵：

• 上下文信息儀表盤：告警直接鏈到儀表盤，顯示告警相關的原始數據，以及相關的上下文數據（譯者注：只鏈到儀表盤其實不夠，還應該鏈到相關的日志、trace、事件等）。
• 多維度的數據分析：允許工程師根據不同的維度對數據進行分析，以進一步縮小問題范圍。
• 充分利用現有埋點數據：假設每次都有完美的數據埋點是不可能的，所以充分利用既有的數據非常關鍵，但需要盡可能按照場景化的方式來串聯數據。

工具和數據：

• 儀表盤
• 指標
• 日志

第三階段：定原因

想要分析問題的原因，就需要找到相關服務的 owner 一起配合，但是服務的依賴關系錯綜復雜，想要找到服務依賴鏈路上的所有 owner 并不容易。

好的可觀測性實踐，可以給工程師一個更直觀的視角，揪出那些引起指標異常的罪魁禍首。另外，它也提供了修復底層問題的洞見，以避免事故再次發生。

成功的關鍵：

• 易于理解服務依賴拓撲關系：對于當前正在故障的服務，快速圈定其上下游依賴。
• 在不同的工具和數據之間串聯跳轉的能力：對于復雜的故障，您需要在日志、鏈路、指標之間反復跳轉，理想的情況是在一個單一的工具中完成。
• 確定根因的時間：有時候無法避免在故障期間做根因分析，而在這些情況下，通過在告警通知或儀表板上顯示出可能的故障原因，可以減少確定根因的時間。

工具和數據：

• 鏈路追蹤
• 日志
• 指標
• 儀表盤

結論

優秀的可觀測性可以帶來競爭優勢、世界一流的客戶體驗、更快的創新和研發人員的幸福感。但是，僅僅關注于輸入和數據（三支柱），組織是無法做到優秀的可觀測性的。通過專注于本文提到的『三階段』以及面向結果的方式，團隊就有望落地優秀的可觀測性實踐！

本文翻譯自：https://thenewstack.io/beyond-the-3-pillars-of-observability/，國內來看，Martin Mao 的這個理念和快貓的理念如出一轍，如果您也需要這類面向結果的新式可觀測性系統，可以了解一下快貓的產品。