為什麼可觀測性是雲原生系統的生存條件

可觀測性不是雲原生系統的附加功能，而是維持穩定、控成本與快速排障的基本能力。

我認為，可觀測性不是雲原生系統的加分項，而是操作層的基本要求。容器會在幾秒內啟動又消失，服務會跨叢集拆分，流量會隨著自動擴縮不停改變；在這種環境裡，只看固定儀表板，等於拿地圖去解釋地震。

監控可以告訴你 CPU 高了、錯誤率升了，但它通常無法回答「為什麼」：為什麼某次 checkout 失敗只發生在某個區域、某個瀏覽器版本，或某次服務網格改路由之後 latency 才突然暴增。這個落差，就是可觀測性存在的理由。

第一個論點

雲原生複雜度已經超過傳統監控的設計邊界。監控是為了相對可預期的環境而生，前提是你大致知道故障模式長什麼樣。但現代平台由微服務、短生命週期基礎設施、第三方依賴與頻繁部署組成，變化本身就是常態。CNCF 一再把這類系統描述為充滿未知未知數，這不是修辭，而是日常。

分散式追蹤最能說明問題。一次使用者請求可能先經過 API gateway、驗證服務、快取、資料庫，再回到前端腳本才失敗。若你只看單一層級，就只能猜；若你能串起整條路徑，就能判斷是慢查詢、壞版本、網路跳點，還是前端回歸。這不是監控的升級版，而是完全不同的運作模型。

第二個論點

可觀測性也是成本控制工具，不只是除錯工具。Gartner 曾警告，雲原生應用的成本會隨 telemetry 量上升而增加，這句話在實務上非常直接：資料不是越多越好，因為每一筆 log、metric、trace 都可能變成儲存費、索引費與查詢費。

因此，成熟的 telemetry pipeline 不會把所有資料永久留存，而是清楚決定哪些要高保真保存、哪些可以抽樣、哪些只需短期保留。這種紀律會直接影響 MTTR 與 MTTD，因為團隊少花時間撈資料，多花時間修問題。對電商結帳、登入流程或 API 服務來說，少一小時的故障時間，往往就是少一筆明確的營收損失。

反方可能怎麼說

最強的反對意見不是說可觀測性沒用，而是說它很容易變成昂貴、吵雜、組織膨脹的代名詞。很多團隊一口氣買多套工具、把所有 log 都灌進去、再做一堆沒人信任的 dashboard，最後得到的是另一層複雜度。這種情況下，懷疑者反對的其實是「收集更多資料」的迷信。

這個批評有一半是對的。若沒有治理，observability 確實會失控；若沒有標準，資料只會越堆越亂。真正的問題不是要不要可觀測性，而是要不要規模化地管理它。OpenTelemetry、統一的資料策略、抽樣與保留規則，才是把訊號變成洞察的前提。

所以，我不接受「既然做不好就別做」的結論。限制是真的，但結論錯了。退回基本監控只會讓你在複雜系統裡更慢、更盲、也更貴；正確做法是把可觀測性當成平台能力治理，而不是把它當成一組工具採購。

你能做什麼

如果你是工程師，請先為「你現在還不知道怎麼問的問題」做 instrumentation，而不是只為現有 dashboard 補資料；如果你是 PM，請把可觀測性視為產品基礎設施，因為它直接影響使用者體驗與發版信心；如果你是創辦人，請投資能降低 MTTR、統一 telemetry、避免工具失控的平台工作。雲原生系統的競爭力，不在於你收了多少資料，而在於你能多快把跨層訊號轉成可執行的判斷。