大家好，我是伐伐伐伐木工
今天要與大家分享 Observability，本篇內容的重點如下
終於要進入主題可觀測性，可觀測性 Observability 簡稱 o11y
可觀測性一詞是 1960 年由工程師 Rudolf E. Kálmán 創造，發展至今在不同的領域意味不同的描述。他在所發表的論文中介紹一個他稱為可觀測性的特徵用於描述數學控制系統，在控制理論中，可觀測性被定義如下
Observability is defined as a measure of how well internal states of a system can be inferred from knowledge of its external outputs.
從對系統外部輸出的資訊推斷系統內部狀態的能力，這裡的資訊指的是收集到的遙測(Telemetry)資料。
看過很多關於可觀測性的定義，自己最喜歡是 Lightstep 提供的定義
Obsevability is defined as the ability to measure the internal state of a system only by its outputs
自己對於其理解是 measure 蒐集 log、metrics、trace 等遙測數據。internal state 是系統發生什麼問題，為甚麼發生及如何修復。outputs 是哪裡有問題、甚麼是慢的、需要做甚麼來提高性能。
要使系統具備可被觀測性，必須滿足以下
隨著科技技術的不斷創新，軟體架構和基礎設施的演進速度也在快速變化。以下（但不僅限於此）是企業過去在開發系統或應用程式時可能經歷的幾個階段：
在這個階段，應用程式的架構設計相對簡單，商業需求還不是很複雜，因此架構通常不會對模組進行太多的切割。應用程式運行在單一執行緒（Process）中處理單一請求。測試和問題排除相對簡單。部署通常在虛擬機器（VM）或機房（IDC）中提供給使用者使用。
隨著雲端技術的出現，企業開始嘗試將應用程式部署到雲端基礎設施即服務（IaaS）上，或結合公有雲和私有雲的優勢。它們可能在私有雲中處理機密資料，並在公有雲服務上處理其他資訊。開發人員在應用程式開發和整合方面有更多的機會與雲端服務整合。這一階段也涉及選擇在雲端上使用適合的服務。
隨著雲端技術的逐漸成熟和穩定，企業可以利用越來越多的雲端基礎設施服務和新服務。架構設計變得更加複雜，分散式系統架構成為許多討論的焦點。資料庫從機房遷移到雲端上，並使用像RDS、DynamoDB、Redis 等雲端資料庫服務，使雲端開發和管理更加便捷。架構也變得更加靈活，以滿足企業需求。同時，容器化技術（如Docker）的成熟也開始引入新的可能性。
軟體架構從單體式(Monolithic)演變為微服務(Microservices)、無伺服器（serverless）和服務網格（service meshes）等各種可能的組合。主要目標是減少服務之間的相依性，提高擴展能力與故障時的隔離與可用性。
帶來了好處也衍伸了一些有趣的議題，服務越切越細、分散式系統其也帶來複雜性，監控與測試變得更為複雜，如何在問題發生的第一時間定位異常的服務也變得更重要，在 Google 文章中 DevOps measurement: Monitoring and observability 提到要在監控和可觀測性方面做得出色，您的團隊應該具備以下特點：
上述內容聽起來很抽象，白話點背後是希望可以回答以下問題
目的是希望工程團隊可以理解並解釋系統的現況(增加系統透明度，而不是靠通靈)，當系統出現問題時，可以第一時間了解爆炸範圍，進行緊急問題的處理已加速恢復的時間。且無須發布新的程式碼，提高系統的穩定性和可用性，也是現代化應用程式非常重要的特性之一。
有想了解更多關於可觀測性的內容可以參考 CNCF 的白皮書，Git 上面的是完整版，Google 文件的是眾多大神在討論時的版本，可以更了解細節，對其有興趣的朋友可以參考看看。
可觀測性白皮書 :
以上是今天的分享。下一篇要來探討可觀測性與監控的差異，如果有任何疑問或想法，歡迎留言提出討論 !
DevOps measurement: Monitoring and observability
What is observability and why is it important?
What is DevOps Observability (Importance & Best Practices)
iThome鐵人賽
看影片追技術