作為一名半路出家的工程師，去年因為工作需要，開始關注業界在實踐可觀測性工程的方法以及心得。從 observability 1.0、2.0 到現在 3.0 問世，再到許多工具的使用，例如 Metrics 的監控工具 Prometheus、使用 Elastic stack 收集 logs，最後因應微服務的興起，Traces 的監控也變成不可或缺的一部分。

本身有幸在擔任 SRE 的第一份工作中，就有從零到一建構一套監控系統的機會。但是，當時的我專注於學習工具的使用，認為把工具架設好、告警能成功發出，就算是實踐可觀測性工程了。一年過去，有了一個機會進入到新團隊，非常巧合地第一份任務就是建構一套適合團隊的監控系統。這次導入系統的心情，和一年前卻有很大的不同。

一年前的我，專注於工具的使用，卻忽略了可觀測性對於團隊的意義是什麼？它能怎麼幫助團隊快速定位問題？可觀測性之於 SRE 這個角色又是什麼？導入可觀測性將會有不小的成本花費，那麼它能為商業產品面帶來哪些好處與貢獻？一年後的我，在動手架構系統之前，終於開始思考這些問題。

近幾年不管是在研討會上或者社群中，也看到許多關於可觀測性工程的分享與討論，而我也從中吸收了許多的知識以及前輩的經驗。所以，今年想透過鐵人賽，來記錄我作為一名 SRE，重新學習可觀測性工程的點點滴滴。同時，也希望能透過這篇系列文與這個領域的前輩們互相交流，持續學習進步。

系列文架構

本系列將圍繞三大主題展開，希望能為正在思考如何為團隊建立可觀測性能力的工程師，以及想了解現代監控系統設計思維的 SRE，提供一些實用的思考框架和實踐經驗。

Observability 的概念與哲學

• 什麼是Observability?
• 從監控到可觀測性的演進脈絡
• Observability 之於 DevOps / SRE 的意義

OpenTelemetry 深度探討

• OpenTelemetry 核心概念與架構設計
• 遙測數據收集的實作概念
• 實際部署配置的經驗

儲存後端的選擇與實踐

• 多後端架構的設計思維
• 實踐 Single source of truth 的設計哲學

每個主題都會結合實際案例和工具操作，避免純理論的討論。希望透過這三十天的分享，能與大家一起探索可觀測性工程的精髓，持續地討論與交流。