Cheng Wei Chen | 艦長

前言 大家好，我是艦長。 你現在閱讀的是 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 生成）...

距離 DevOpsDays Taipei 2025 結束已經超過一個月了，終於提筆以一篇文章記錄這次的活動。 （但其實我還是有偷懶，我直接複製去年文章大部分的架構，再針對每個段落改成今年的內容 XD） （如果有看到文中的紀錄有誤之處，還請通知我修正，謝謝！） 活動基本資料 主辦單位：台灣敏捷社群、DevOps Taiwan Community、Taipei HashiCorp User Group、iThome 官網：https://devopsdays.tw/2025 日期：2025/06/05 ~ 2024/06/06 地點：臺北文創大樓6樓 Keynote：共 4 場 分堂議程：共 35 場 工作坊：共 16 場（其中 3 場是 DevOps Bootcamp） 贊助商：共 20 家（依據活動官網 Logo 計算） 活動人數：超過 850 人 活動共筆：https://hackmd.io/@DevOpsDay/2025 不知不覺又當了一年的組織者 跟大家報告一件事，大家知道嗎？其實我的 MBTI 測出來，好幾年都是妥妥的 I 人。 所以每一次辦完各種大小活動之後，其實我都需要一點時間沉澱，藉此恢復自己的社交能量。 本來辦完去年的 DevOpsDays Taipei 2024 之後，一度有很深的疲倦，心中暗自想著 2024 就當作最後一年吧。 然而，休息個幾個月之後，還是默默的又開始籌備起 DevOpsDays Taipei 2025，想著 2025 的 DevOps Bootcamp 議程該怎麼安排才好。 結果不知不覺間，2025 又辦完了，於是又進入省電模式了。 開放空間會議 同樣的再次重申，「開放空間會議」（Open Space Technology，簡稱 OST）是 DevOpsDays 的一項傳統，不論是在哪一個國家城市舉辦的 DevOpsDays，基本上都會安排這個鼓勵與會者自由交流的活動。...

前言 （感謝敏捷三叔公贈送簽名書一本！） 2024 年底，一則 FB 訊息傳來，原來是「敏捷三叔公」柯仁傑又在寫書了，希望我能為他正在撰寫的書籍內容提供一些意見；對於這種能夠搶先預覽好書內容的要求，我當然是毫不思考立刻答應。 隨著時光來到的 2025 年四月，再次收到敏捷三叔公的 FB 訊息，沒想到這次是三叔公邀請我為他的書撰寫推薦序；對於這種殊榮，我當然更是義不容辭的立刻答應！ 如果你也經常有在注意市面上的軟體測試及 DevOps 相關書籍，不曉得你是否與我有同樣的感受，覺得能找尋到的正體中文資源頗為有限，總是希望市面上能有多一本相關的好書。 如今 2025 年七月，我們終於等到這本由敏捷三叔公 David Ko 柯仁傑撰寫的《軟體測試修練指南：我獨自升級的實戰心法》正式出版上市。三叔公出品必屬佳作，相信這本書能為台灣補足更多關於軟體測試的正確知識與觀念，也能成為下一個敲門磚，讓台灣能有更多關於軟體工程、軟體測試、軟體品質、Agile、DevOps 的好書得以持續出版下去！ 再次感謝敏捷三叔公 David 柯仁傑讓我有機會參與這本書的出版，這本書真的很厚，他想談的內容真的很多，我當時提供回饋意見時，還希望他能寫更多一點！ （跟 10 元一樣厚的書！） 總之，強烈推薦大家快點去買好書，既能補充知識，又能支持敏捷三叔公與出版社，一舉數得喔！ 購書連結：天瓏網路書店 下面附上我所寫的推薦序全文，這次撰寫的文字風格比較正經一些，反倒是三叔公自己取的書名「我獨自升級」有趣多了。 推薦序全文 再多來一本吧！我們需要更多軟體測試的優質好書！ 如果你也是投身於軟體領域的工作者，你多半也體驗過因為軟體出現Bug或品質不良而讓你頭痛的時刻。軟體品質是一個所有使用者都十分在意的軟體基本需求，但對於軟體開發團隊而言，「品質」卻是一個需要透過整體軟體開發生命週期疊加累積才能交付的成果。 面對「提升軟體品質」這個目標，通常我們總是會說「下次我們要好好的做測試」，然而偏偏軟體測試是一項我們都認同它超級重要，但卻難以找到方法，將其有效融入日常開發流程中的艱難技藝。我們真的需要更多優質的軟體測試學習資源，幫助我們可以從整體觀念架構認識軟體測試，知道它知易行難及易學難精之處。 柯仁傑，在台灣敏捷社群中被暱稱為「敏捷三叔公」，是我十分敬重的 Agile 與軟體測試領域的前輩。他在台灣敏捷社群及軟體測試領域深耕多年，擁有扎實的軟體測試經驗。在這本《軟體測試修練指南》書中，他將自身累積數十年的軟體測試經驗轉化為有系統與架構的文字，涵括軟體測試基礎、方法論、到測試管理及人才培育多個主題，為我們提供了一份難得的學習指引。 你也是一位正打算加強軟體測試能力的工程師嗎？又或者，你是一位希望幫助團隊更落實軟體測試的倡議者？那麼，一起來閱讀本書吧！透過敏捷三叔公的視角，幫助你理解軟體測試在實踐中可能遇到的挑戰與應對之道，讓這本書為你的軟體測試學習之路，增添一份助力！ DevOps Taiwan Community 志工 & DevOpsDays Taipei Co-organizer 陳正瑋（艦長）

Every year, iThome hosts a challenge where IT practitioners write a blog post every day for 30 days. (iThome is a well-known IT news media in Taiwan.) This year, I decided to join this challenge and chose a frequently asked question: ‘Why do you pay for GitLab?’ as my topic. You can find all 30 posts on iThome’s website. If you’re interested, feel free to check out the links below....

前言 每一年 iThome 都會舉辦「iT邦幫忙鐵人賽」——讓 IT 人挑戰，連續 30 天不間斷每天寫一篇文章。 今年因故臨時決定參賽，選了一個自己過去經常被問到的問題「付費版 GitLab 到底差在哪裡？」來當作內容主題。然而這畢竟是一個會談到「付費功能」的內容主題，所以恐怕會變成某種「功能介紹」、「付費功能推廣」的「工商文」，所以最後就直白的將參賽主題訂為《就是工商，為什麼要使用付費版 GitLab？》。 30 篇文章已經全部發佈在「iT邦幫忙」網站上，我暫時也沒有將文章搬家的計劃，因此對於該系列文有興趣的讀者，可以直接透過下面整理好的超連結前往閱讀。 由於鐵人賽是連續 30 天的考驗，所以經常會參賽到一半開始沒靈感，或是不小心歪到偏離參賽主題的內容去；我這次也很明顯的出現這種狀況，所以下面的超連結已經幫大家將各篇文章的內容分類，讓各位可以比較容易的找到想讀的內容。 文章超連結 參賽開場白 這是最沒內容的開場白，如果你想感受一下我當初起心動念臨時參賽的心情，再去閱讀吧！ Day 1：為什麼要寫這個主題「就是工商，為什麼要使用付費版 GitLab？」 企業通常會為了哪些功能付費 一般使用者與企業，兩者會願意付費的功能是不同的。 Day 2：企業在意的付費功能可能跟你想的不一樣 Day 3：企業通常都在意哪些功能 GitLab 付費功能介紹 這次系列文有挑了幾個「付費功能」來介紹。 Day 4：自架 GitLab 的高可用方案—GitLab Geo Day 5：如何避免因為 AD 故障而無法登入 Self-managed GitLab？ Day 6：GitLab 請賜給我更多的 User 權限自主權！ Day 7：稽核你不要來，這裡沒有什麼好查的啦～ Day 8：用數據來證明你導入 DevOps 是有效的！ Day 18：Security 功能 - Pre-build scanning Day 19：Security 功能 - Post-build scanning Day 21：GitLab 的 AI 功能 Duo Day 22：GitLab 的 Incident management 功能 Day 23：GitLab 的 Portfolio Management 功能 GitLab 歷史與功能發展 這邊要提醒一下，歷史與功能發展我並非用一個很有系統的方式整理，而是我自己在讀完 GitLab 公開的 History，以及每一則 GitLab Release note 後，自我心證的挑了一些資訊記錄下來，因此這數篇文章比較像是我個人的筆記，裡面比較有可讀性的只有各篇文章文末的感想。...

如上一篇文章提到的，延續去年，今年在 DevOpsDays Taipei 2024 也規劃了一軌的 DevOps Bootcamp，其中安排了兩場體驗工作坊。 工作坊最終在經過理想與現實的交戰之後，決定由盧建成與我各自負責一場工作坊。 另外，由於 DevOps Bootcamp 整軌議程會固定使用瓶蓋工廠台北製造所 的 M 棟場地，因此預設這會是至多 160 人參與的工作坊。 主題發想 由於是「體驗」工作坊，重點在於「體驗」，因此打從一開始，我就設定工作坊的形式是不需要使用「電腦」，並且要有大量的討論與交流。 但問題是要「體驗」什麼？ 在與盧建成討論之後，我希望他能繼續銜接 Biz 與 DevOps 的議題，讓新手知道 DevOps 不能少了 Biz。因此他那邊會從 BizDevOps 為出發點，思考關於團隊協作、文化、溝通有什麼適合新手體驗的主題。 而我這邊則繼續照顧最常見的新手需求之一，即是 CI/CD；畢竟談到 DevOps 時，大家最常聽見的第一句話依舊是「你們有做 CI/CD 嗎？」。因此我繼續從 DevOps 最基本的工程實踐 CI/CD 為出發，來思考有什麼適合放在新手村的體驗工作坊。 構思內容 我自己過去設計過一些 DevOps 工作坊，也講過幾場 GitLab CI/CD 實作工作坊，算是插電與不插電兩種類型的工作坊都有一些經驗。更早之前在 2017 第一屆的 DevOpsDays Taipei 時也參加過 EXIN 的鳳凰專案沙盤工作坊，以及過去也參加過幾次敏捷社群其他講師有使用大量「教具」的工作坊。 因此一直以來，我就很想要設計製作一套自己的 DevOps 教具與課程，只是遲遲未能找到合適的機會將它實現。（其實我還有另一份胎死腹中的 DevOps 教具 idea，還留在我的筆記本中。） 綜合上面各種過去經驗，以及這次 DevOps Bootcamp 新手村的主題發想，我決定在這次的「體驗工作坊」，讓新手認識 CI/CD 是一件涉及範圍可以很窄也可以很廣的一件事；它本質上是一項「變革」，根據你組織與團隊的現況，不同組織當前要處理的議題範圍是不同的。因此最後我決定，不如就讓大家一起在工作坊上，感受一條龍工程師的痛苦吧！ （迷因出處：網路迷因圖） 補充：我覺得新手需要的並不是那些單一的工具細節，雖然使用哪一套 CI/CD 工具也是需要思考的議題，但那並非最重要的事。...