序

最近幾年，“可觀測性”（observability）從小眾的系統工程師社區逐步延伸到了更廣泛的軟件工程師社區，隨著這個術語變得越來越有影響力，其不可避免地與“監控”（monitoring）產生了一些重疊。

當然，接下來的事情也不可避免地發生了，監控工具的提供商開始選擇并使用那些試圖區分可觀測性和監控的哲學和社會技術人員所使用的語言和詞匯。這些人也充當了“把水攪渾”的角色，使得廣大的技術從業者無法有效地分辨“監控”與“可觀測性”的真正差異。

把可觀測性視為監控是非常愚蠢的。可觀測性并不是一個純粹的技術概念，無法通過購買可觀測性工具（無論那些監控廠商怎么說）或者實施開放性標準來實現。相反，可觀測性更像是一種社會技術理念，成功地應用可觀測性要依靠整個組織的文化，其愿意選擇正確的工具去幫助和改善軟件的開發、部署、調試和運維。

在大多數（甚至是全部）場景中，團隊需要有效地應用監控和可觀測性來成功地開發和運維服務。但是，想成功實施要先從根本上理解監控和可觀測性兩者之間的差異。

區分監控和可觀測性的主要依據是基于系統行為的狀態空間，以及人們希望探索狀態空間的方式和探索的詳細程度。“狀態空間”指的是系統在不同階段所要關注的最重要的行為，比如系統設計階段、開發階段、測試階段、部署階段、用戶使用階段和故障調試階段。系統越復雜，這種狀態空間也就越多，而且互相之間的轉換也越多。

可觀測性允許這種狀態空間被精心繪制出來，并且會對其進行深度探索，以便幫助我們理解系統行為中不可預測的、長尾的或者各種狀態下的分布情況。這需要我們對整個系統有更深入的了解。相比之下，監控系統往往只是展示了系統整體運行狀態的大致走勢。

因此，從收集數據到如何存儲數據，再到如何探索這些數據來更好地理解系統行為，這一切都取決于你的目標是監控還是可觀測性。

在過去的幾十年里，監控的理念影響了無數工具、系統、流程和實踐的發展，其中許多已經成為事實上的行業標準。這些為特定領域設計的監控工具已經出色地完成了任務。但它們不能，也不應該被稱為“可觀測性”工具并推銷給無法區分二者的客戶。這樣做除了給客戶帶來大量時間、精力和金錢損失外，幾乎沒有任何明顯的好處。

此外，工具只是問題的一部分。一家公司因構建和使用了可觀測性工具而獲得成功并不意味著同樣的事情會發生在其他的組織里。因為大部分情況下，該公司并不會告訴大眾其在應用工具過程中所做出的組織文化上的調整和背后一步步演進的過程，以及解決所遇問題的方法，等等。

如果不首先在公司內部建立一個有利于團隊成功的工程師文化，那么自建或購買最好的可觀測性工具也解決不了問題。一種根植于監控準則（儀表盤、告警、靜態閾值）的心態和文化無助于釋放可觀測性的全部潛力。可觀測性工具可以幫助團隊訪問大量的運行態的細粒度數據，但成功地理解堆積如山的數據從而在軟件的整個生命周期中獲得收益，才是明確使用該工具的價值，也才能體現出可觀測性本身的價值！這個過程本身就需要用假設驅動的、迭代調試的心態來逐步推進。

簡單地使用最先進的工具并不能自動在實踐者中培養這種心態。如果不把這些想法提煉成具有交叉性的實際解決方案，那么就是在對監控和可觀測性之間模糊的哲學區別夸夸其談。例如，本書中有些章節對將日志、指標和鏈路作為“可觀測性的三大支柱”持負面看法。雖然批評沒有什么意義，但事實上，指標、日志和鏈路一直是人們遙測實際運行系統的手段，其實我們一直在使用“三大支柱”，所以基于此來討論可觀測性也不可避免。

與在現實世界中構建系統的實踐者產生共鳴的最佳方式，不是抽象的、不切實際的理念或者概念，而是能夠解決他們所面臨的技術和文化問題的切實可行的藍圖。本書試圖通過提供這樣一個具體的藍圖，幫助人們將這些理念付諸實踐，從而彌合可觀測性的哲學原則與實踐之間的鴻溝。

本書沒有關注協議或標準，甚至各種遙測信號的低級表示，而是將可觀測性的三大支柱設想為結構化事件、假設的迭代驗證以及“核心分析循環”的三位一體。根據第一性原理對可觀測性的構建塊進行整體重構，有助于強調僅通過遙測信號（或簡單使用獲取這些信號的工具）不能最大限度地觀測系統行為。本書也闡明了工程師在團隊中建立可觀測性文化時可能面臨的挑戰，并就如何以可持續的方式開展這項工作提供了寶貴的指導，這有利于可觀測性實踐者獲得長期的成功。

——Cindy Sridharan

基礎設施工程師

2022年4月26日于舊金山