什麼是可觀測性(Observability)? 為什麼需要可觀測性?
2025年7月2日
可觀測性 (observability) 是近年來在軟體工程領域相當常聽見的一個詞，然而可觀測性是什麼? 為什麼需要為系統建立可觀測性? 在這一期的主題文中，我們將來一探這個可能有點拗口的詞 (備註：因為 observability 這個詞有點長且不好唸，因此業界有另一個叫 o11y 的簡稱，所以當聽到 o11y，就是在指可觀測性)。
為什麼需要可觀測性?
在談可觀測性之前，想先請大家回想自己在工作上實際寫程式時，有多少比例的時間在解 bug? 相信即使是一個很完善的系統，出現 bug 仍是難免的。這時就出現一個很關鍵的點，當發現有 bug 時，該如何快速定位問題出在哪裡，然後直指問題核心，讓問題能更快被解決?
要能夠快速地定位出問題，系統的可觀測性就會非常重要。
這邊讓我們用看牙的例子來做比喻。以多數人都有經驗的看牙醫來說，今天假如你的某顆牙齒覺得痛，這時「痛」這件事，就像在一個系統中的警報 (alert)，透過疼痛讓你意識到有問題；這就像我們在 軟體工程師該如何做好監控 (monitoring)？ 談到的，一個系統中需要機制來讓開發者與維運人員，知道系統中有問題出現。
也如同「痛」是有分等級的，假如今天只是小痛，可能多數人會忍一下，觀察一兩天，如果還繼續痛才去看牙醫；但如果是大痛，可能會飛快就近找一個診所或醫院，趕快做檢查與治療。在軟體系統的監控與警報系統，也會需要區分嚴重等級，例如 P0 是最重要，P1 是次重要，然後再來是 P2、P3 以此類推。如果看到是 P0 的問題，需要放下手邊做的是馬上去解決問題，但假如是 P3 的則不需用這麼緊急。
但是如同今天牙痛去看牙醫，不能只有「痛」這個機制，因為只有痛，醫生只能旁敲側擊式地推斷問題出在哪，例如會問是哪裡痛、怎麼樣的痛法，但這樣很難快速找出最根本的問題。因此相信多數人現在去看牙醫，醫生都會先幫忙照一張 X 光片，然後根據 X 光片以及其他的資訊，綜合判斷下告訴你問題可能出在哪裡。
這邊的 X 光片就是增加可觀測性的手段，透過 X 光片，牙醫師可以更清楚了解蛀牙的缺損、牙根有沒有破損、過去做的根管數目與鈣化狀況，這些資訊能讓牙醫師更有效判斷應該採用哪種方法對症下藥。
同樣地，假如今天在系統當中出現一個 bug，身為工程師要去判斷問題根本原因，就會需要有對應可觀測的工具與手段。不然只能用瞎子摸象的方式去推敲，這會讓整個 debug 過程變得非常沒有效率。
讀到這你可能會問，所以什麼是可觀測性?
什麼是可觀測性 (observability)?
在理解完為什麼需要可觀測性後，讓我們回過頭來理解什麼是可觀測性。如同上面段落的比喻，所謂的可觀測性，是指能去衡量一個系統內部狀態的能力。如同 observability 這個字是由 observe (觀測)，以及 ability (能力) 所組成的，因此當一個系統是可觀測的，意思是開發或維運的人，可以很輕易地去觀測到系統內部究竟發生什麼事。
可觀測性在一個複雜的系統會顯得特別重要，舉個具體的例子來說，在一個電商的客服系統中，今天使用者做了某個操作失敗了，可能發生問題的地方非常多，有可能是前端出問題，也可能是後端出問題。假如是後端出問題，那麼是後端背後對接的多個不同微服務中的哪個出問題? 假如沒有好的可觀測性，開發者要 debug 時就會非常痛苦，需要一層層追。但如果有好的觀測性，就可以一眼看出問題出在哪裡。
在 軟體工程師該如何做好監控 (monitoring)？ 談到的監控 (monitoring) 可以讓開發者知道出問題了，而可觀測性 (observability) 則是讓我們知道哪裡出問題、為什麼出問題。
閱讀更多
不過，要如何提升一個系統的可觀測性呢? 這就不能不談可觀三支柱 -- 指標 (metrics)、日誌(logs) 以及追蹤 (traces)，以及提出三支柱不足夠的可觀測性 2.0。