前言
大家好，我是艦長。
我本來打算參加 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 生成）
好了，第一篇文章就到這裡啦！後面的內容就讓我慢慢寫了。
系列文連結
此系列文持續撰寫中，陸續更新連結。
