Data Observability

前言 大家好，我是艦長。 你現在閱讀的是 Data Observability 系列文，此系列文的內容是依據我 2025 在 DevOpsDays Taipei 2025 分享的 25 分鐘短講「資料可觀測性 Data Observability」，將簡報內容逐一拆解為多篇短文。 前一篇文章我們聊到「如何妥善管理與應用 Data」並不只是一個純粹的技術議題，作為開場讓大家知道其實 Data 有很不技術的一面。（謎之音：都是人的問題！） 在本系列文繼續聊更多 Data 的話題之前，今天我想要做一個比較，我們先回到軟體開發領域，看看軟體圈都在意些什麼事情。 一切都是為了替使用者帶來「價值」 如果你問軟體工程師，你們在開發軟體時，都在意些什麼？為什麼你會選擇採用某些軟體工程的實踐方法？你都在考量些什麼？ 前述這些問題，你可能會得到許多不同的答案像是「為了寫出乾淨的程式碼」、「為了打造可擴展的軟體架構」、「想要導入最新的軟體技術」、「為了確保服務穩定」……。 讓我們再繼續追問，那為什麼要「寫出乾淨的程式碼」、「打造可擴展的軟體架構」、「導入最新的軟體技術」、「確保服務穩定」? 有 Sense 一點的軟體工程師可能就會回答你——為了替使用者帶來價值！ （謎之音：你確定軟體工程師會這樣回答你？） 乾淨的程式碼、良好的軟體架構與系統架構、高可靠性的服務⋯⋯這些都是「手段」或「產出」，而做這些事情的結果，對軟體開發團隊來說，當然就是為了讓團隊交付給客戶的軟體，是有品質的、高可靠的、可以滿足使用者需求的，是能夠為使用者帶來價值的。（謎之音：然後客戶樂意付錢，公司賺大錢！） 那麼既然我們聊到「價值」兩個字，到底裡面包含了什麼？ 我自己覺得這是一個大哉問，因為每個使用者想要的價值不同，但多半會有一些常見的層面。 軟體在工程面的品質：也就是軟體有沒有出現令人傻眼的 Bug？會不會突然閃退？軟體背後的雲端平台是否可靠？能否因應大量暴增的使用者連線？是否有後門資安漏洞？ 軟體的功能是否滿足需求：軟體功能再強大，但無法滿足使用者需求都是白搭。像是廠商宣稱軟體可以做到無痛的自動雲端更新，隨時保持在最新的版本，但客戶說不好意思我們家禁止連上外網；又或者是使用者想要一個可愛溫馨風格的UI，然後廠商端提供的卻是高冷賽博龐克風格UI。 軟體圈都做了些什麼？ 前面聊完了價值，最後來看一看軟體圈做了哪些事情，是不是都是圍繞著價值呢？ 首先，基本上我們可以說軟體工程的各種實踐，都跟幫助團隊能持續產出高品質、符合需求的軟體脫離不了關係。 像是我們會在意軟體架構 (Software Architecture)，從 Monolithic 、SOA 到 Microservices。 又或者是程式碼的可維護性，我們有 Clean Code、SOLID 原則⋯⋯。 為了讓軟體有一個可靠的運行環境，讓環境管理更穩定，我們有虛擬化技術、容器化技術與 Cloud、Serverless、 Infrastructure as Code、GitOps⋯⋯ 當然別忘了還有大鍋粥 DevOps、SRE、Platform engineering。 軟體圈有各種不同的關鍵字，分別在不同層次幫助團隊可以更快、更穩定的將價值交付到使用者手中。 小結 好了，字數差不多了，我們就在此快速做一個小結。 今天這篇短文其實也是一個鋪梗，我想要讓大家思考一下，軟體圈從古至今的這些方法論、實踐、Keywords 都在做些什麼，都在關心哪些議題，以及解決了什麼問題。 然後順著這個梗，延伸想要問一個問題——「那在軟體圈，我們為 Data 做了些什麼？」 我們有針對程式碼、Infrastructure、軟體開發交付流程、軟體測試、軟體安全性⋯⋯做了很多事情，但是 Data 呢？針對 Data，軟體圈有做了什麼事情呢？是不是相較前面提到的那幾項，稍微生疏一些呢？（當然也可能只是我個人對此生疏，其他資深的軟體工程師對於 Data 也很熟稔。）...

前言 大家好，我是艦長。 我本來打算參加 2025 的 iThome 鐵人賽，也為此提前開始做了一些準備，但8月實在發生太多事了，只好選擇「逃避雖然可恥，但有用」，決定放自己一馬，放棄參賽。 下面先附上我當時想要放在 Day1 的開場白，我本來是期待自己可以參賽的。 時間過得真快，又到了一年一度的 iThome 鐵人賽。老實說，每年快到這個時間都會有一點焦慮，因為總是想要寫點什麼，但又覺得不知道還可以寫什麼（特別是現在 AI 歸納資訊與產文的狀況如此氾濫）。 除了主題之外，也擔心自己會撐不下去，30 天其實不容易（但聽說某人今年開始每天寫一則 #重新認識DevOps 的小短文⋯⋯）；所以為了避免今年參賽無法完賽，就決定偷懶一魚兩吃，將我今年在 DevOpsDays Taipei 2025 分享的 25 分鐘短講「資料可觀測性 Data Observability」，拿來當作今年的鐵人賽主題。 （我真的有許願想要參賽～） 雖然放棄參賽，但已經準備的內容也不想浪費，所以接下來會陸續將這些材料回收再利用，沒意外的話還是會用多篇短文的方式留存在這個部落格。 （題外話，我最近看到一個說法，作者說這時代大家比較能接受的文章長度大約是 500 字，所以後續應該都會將文章內容控制在這個長度。） Data 不只是技術問題 在開始聊資料可觀測性之前，前面我打算先聊一些跟 Data 有關的議題，作為一些背景知識，後續的文章才會切入資料可觀測性，不想看的人可以選擇跳過喔！（喂 首先，就從一個大哉問開始：為什麼「如何妥善管理與應用 Data」並不只是一個技術議題？ 這裡讓我先講一個故事來回答這個問題。 A 公司是一間快速成長的電商，他們內部有多個部門，例如市場行銷、產品與數據分析部門。 為了提升下半年的業績，市場行銷部門規劃了一場行銷活動，目標是針對「特定條件之會員」發送客製化的折價券。 於是收到指令的數據分析部門很快地從資料庫中，撈取了會員名單，交給了市場行銷部門。 隨著行銷活動上線後，乍看之下有不少會員都會來購物，但業績提升狀況卻不如預期。經過追查，才發現原來收到折價券的會員，跟市場行銷部門想的不一樣。 在這個故事中，問題的關鍵就在於兩個團隊對於同一批資料的定義不同。「特定條件之會員」到底是哪一個「特定條件」？舉例來說，可能是特定消費習慣的族群、最近 n 天完成購買的老顧客、最近 n 天新註冊的會員、來自某廣告連結的人⋯⋯。 應該有人會說，這個故事的「特定條件」也太不精準了，這裡還請大家（特別是資料圈與電商圈的各位大大們）鞭小力一點。故事只是為了用來讓大家快速理解我想要表達的重點「Data 不只是技術議題」。 以該故事的情境來說，它其實比較偏向溝通問題，兩個部門對於同一批資料的定義不同，但沒有人意識到這個問題。所以即便他們使用再厲害的資料庫、資料分析系統、最酷的 BI 儀表板，依然發生沒有打中目標客群的問題。 同時這故事也呈現出一個狀況，即是資料的使用者與管理者是兩群不同的人。這其實是另一個問題，也就是説資料使用者只知道自己想要拿到目標 Data，但他不見得會關心，Data 從哪裡來，怎麼產出這批 Data⋯⋯。你不覺得這情境聽起來就很容易會有滿滿的溝通問題？而這就是 Data 圈經常可見的真實場景。 最後，讓我們快速的做一個小結。 Data 不只有如何儲存、處理、取用及分析大量資料的技術議題。 Data 也同樣充滿各種品質、流程、溝通、管理、治理的議題。 就如軟體圈有 DevOps，在 Data 圈也有 DataOps。我們都需要從人、流程、工具多層次來解決其中會遇到的問題。 （此圖片由 Google Gemini 生成）...