Posts

DevOpsDays Taipei 2026 於昨天 6/26 順利舉辦完畢，昨日我早早就陪小孩入睡，但清晨 04:15 左右就一陣清醒，明明身體是累的，但腦袋卻轉個不停。 不知怎麼的，今年的 DevOpsDays Taipei 2026 令人感觸很多，也許是因為 AI 帶來的改變太大？也許是年紀越來越大？也許是發現純粹的社群越來越像是個珍貴的存在。 趕緊動筆，寫下今年的感謝文。 （如果有看到文中的紀錄有誤之處，還請通知我修正，謝謝！） 活動基本資料 主辦單位：台灣敏捷社群、DevOps Taiwan Community、Taipei HashiCorp User Group、iThome 官網：https://devopsdays.tw/2026 日期：2026/06/25 ~ 2026/06/26 地點：臺北文創大樓6樓 Keynote：共 4 場 分堂議程：共 44 場（其中 5 場 DevOps Bootcamp） 工作坊：共 14 場（其中 2 場是 DevOps Bootcamp） 贊助商：共 20 家（依據活動官網 Logo 計算） 活動人數：超過 850 人（與去年相當） 活動共筆：https://hackmd.io/@DevOpsDay/2026 第九屆的 DevOpsDays Taipei 如同我在 Day 1 開場提到的，今年是第九屆的 DevOpsDays Taipei，沒想到默默的這個年度 DevOps 大活動也舉辦了這麼多年。 開場簡報 從第一屆開始計算。 2017 2018 2019 2021 2022 2023 2024 2025 2026 如果 2020 沒有發生疫情，那其實今年就應該是第十屆了。...

前言 大家好，我是艦長。 上一篇文章我們看遍了各家的 Data Observability 定義，本文要繼續認識在 Data Observability，我們會觀測哪些東西。 這裡就直接採用 Monte Carlo 這家公司提出的五大支柱。 第一支柱：新鮮度（Freshness） 新鮮度，即是「你的資料是不是足夠『即時』？」 其實過去 Data 圈在談「資料品質」時，也會關注這個重要項目。 還記得我們前面幾篇文章說過的故事，Data User 發現今天查詢的業績報表數字怪怪的。業務主管記得明明上週有一筆大單，但查看業績報表數字就是對不上。最後向 Data Team 反應才發現是上游的資料管線停擺了一天， 新鮮度關注資料的時效性。你的資料應該要在「預期的時間」內被更新，並且要更新至 Data user 需要的那個時間區段內的 Data。 用比喻來說，就是訂閱的概念。好比訂報紙、固定發刊的電子報、週刊、雜誌⋯⋯ 每週四12:00固定會發刊的付費電子報，結果已經週四13:00 了，你還是沒收到。或者你準時收到了，但內容居然跟上週一樣。 這就是新鮮度想要觀測的。 第二支柱：資料量（Volume） 資料量，這個字面意思應該不用解釋吧。 這也是一般在談資料品質、資料驗證時大家都會想到的項目。 你上游說每次都會提供 10 萬筆資料，那我就來驗收是不是有10萬筆，結果一驗怎麼只有 99999筆。 又或者是，最近半年內每個月的訂單資料大約都是 1萬筆上下，怎麼忽然11月暴增為 5 萬？這是不是有異常？ 資料量 Volume 觀測的就是你資料的「量」是不是吻合你的預期。 第三支柱：品質（Quality） Quality 品質，這一項就有點意思了，因為單看 Quality 這個字，似乎是直接把過去資料圈一直在談的 Data Quality 整個放進來當成一個觀測項目。 因此也有另外一個說法，是改用 Distribution 分佈這個字，更精準表達我們要觀測的是資料的值（內容）是否都落在合理的範圍。 舉例來說，你這一批資料是關於台灣的便利商店，結果在經緯度這一欄卻出現了非洲的位置，顯然資料必有問題；又或者這批資料關於人事，其中一個欄位是人員的年齡，但卻出現了四位數字的資料，這資料也必然有問題。 我個人是比較喜歡分佈這個說法，一來可以避免跟其他的 Data Quality 混用，導致議題混淆。另外分佈，更能表現出統計學的意味，我們是用一種科學的方式在評估資料是否吻合我們的期待。 第四支柱：結構（Schema） 資料結構，這也是一個過往以來不論是軟體圈或 Data 圈都會關注的項目。 「欸，明明說好資料會有 10 個欄位，怎麼少了一個？」 「欸，明明說好這個欄位是整數，怎麼取出來有小數點？」...

很高興的，再次看見有認識的社群朋友出書，也很榮幸能為其書籍撰寫推薦序，當然要特別留下一篇文字作為紀念，並且幫忙推銷一下！ 畢竟這年頭，還願意扎扎實實寫書的人真的是越來越少了，任何願意將自己的經驗、知識轉化成文字，集結成書的人，都是令人尊敬的勇者！ 這次要分享的是台灣獲得 Grafana 官方認證的社群專家劉義瑋（Blueswen）所出版的新書《Grafana Zero to Hero：從視覺化到智慧監控，打造全知視角的可觀測性平台》！ Zero to Hero 這是一本書如其名的書，寫給所有想要從零開始認識 Grafana 的工程師。從基礎開始認識 Grafana，最後進入到管理與應用，並且作者亦準備了多個 Lab，幫助讀者能實際的練習操作。 只要你的團隊有在收集 Mertics，有打算製作維運用途的 Dashboard，多半都會經手到 Grafana 或類似的工具，甚至如果你有在使用一些開源專案，是有包含後台、管理介面的大型服務，很多專案也都會默默的直接整合 Grafana。 Grafana 對於維運、監控及可觀測性來說，已經是一個十分常見的技術選項，但它確實是一個需要一番著墨才能用得好的工具，而想要用得好，那就需要有前人的智慧與經驗了。 最後，就用一句引言來做個結尾： 「可觀測性從來不是一次性的專案，而是一個能隨系統演化持續疊代的過程。」 這一句引言出自另一位推薦者 Marcus Tung 所寫的推薦序，我覺得是一句十分貼切的話。 有時我們會看到某些工程師輕忽了系統維運的難度與專業性，以為只要把一些套裝工具設置好，就算是搞定了維運，但真實場景往往不是這麼簡單的一件事，維運是一件需要長期投資的工作，你需要定期投入資源去檢視、演化、改善，而監控與可觀性在其中更是如此。 這時代的軟體（服務）已經不單需要軟體層面的高品質，系統維運也需要高品質，只有讓 Dev 與 Ops 都能提供良好的工作成果，才能持續幫助企業為客戶創造價值。 下面附上我所寫的推薦序全文，請大家多多支持劉義瑋的新書《Grafana Zero to Hero：從視覺化到智慧監控，打造全知視角的可觀測性平台》。 推薦序全文：從零開始的監控及可觀測性英雄之路 搞定監控及可觀測性，從來就不是一件簡單的事。 如果你是一位 DevOps / SRE、系統或維運工程師，你肯定體驗過系統監控不如預期的痛苦。我們都渴望建立完善的監控儀表板，期待它能在問題發生時為我們指引方向，但往往理想豐滿，現實骨感。監控看似簡單，實則水很深，更不用說倘若連監控都窒礙難行，那更遑論實踐更進階的可觀測性了。 我們需要良好的入門學習資源，而本書作者劉義瑋，正是帶領我們踏上這趟旅程的絕佳人選。 自 2022 開始，可觀測性的主題逐漸在台灣技術圈浮現，從那時開始我就注意到有越來越多人在分享相關主題，然後就發現了這位我尚未推坑過，但早已自行入坑積極分享的劉義瑋。他不僅多次登上 DevOpsDays Taipei 及 DevOps Taiwan Community 的講台，更是獲得 Grafana 原廠認證的 Grafana Champion，是一位樂於分享且擁有豐富經驗的專家。 義瑋將他豐富的 Grafana 運用經驗，轉化成這本為了初中階學習者設計的《Grafana Zero to Hero》。書中廣泛介紹在使用 Grafana 時需要注意的各個重要面向，更貼心地在每一章附上 Lab 範例；讓讀者可以如義瑋自己在書中所引用的金句「傑出的藝術家模仿，偉大的藝術家盜竊」，透過模仿、練習、親手操作，得以更深的去體會如何運用 Grafana。...

前言 大家好，我是艦長。 在上一篇文章中，我們有看到 Gartner 的 Hype Cycle，清楚地看到「Data Observability」這個關鍵字是有被關注的。 本文我們就來做個「名詞解釋」，比較不同來源的定義，看看什麼是 Data Observability。 各種 Data Observability 定義 下面我整理了幾個不同的定義來源： Monte Carlo Data： 如上一篇文章提過的，作為 Data Observability 主要的推廣廠商之一，Monte Carlo Data 當然有定義什麼是 Data Observability。 “Data observability provides full visibility into the health of your data and systems so you are the first to know when the data is wrong, what broke, and how to fix it.” （定義出處：https://www.montecarlodata.com/blog-what-is-data-observability/） IBM 同樣上篇文章提到，跨足全球的 IT 顧問及解決方案巨頭 IBM，也沒放過 Data Observability，他們提出的定義如下。 “Data observability refers to the practice of monitoring, managing and maintaining data in a way that ensures its quality, availability and reliability across various processes, systems and pipelines within an organization....

前言 嗨，大家好，我是艦長！ 歡迎來到 Data Observability 系列文的第 8 篇。 本文要實現上一篇的承諾，接下來真的要開始談「資料可觀測性」（Data Observability）。 Data Observability，它是一個新興的 Buzzword？還是已經成為 Data 圈的常見實踐？本文我們先不過度深入，先從這關鍵字的趨勢來認識它。 網路關鍵字趨勢 首先我們先從 Google Trends 開始，看看這個關鍵字的搜尋趨勢。 打開 Google Trends，輸入「Data Observability」，從圖中可以發現在 2019 年以前，這個詞幾乎無人關注，直到 2020 年12月才開始有了起色，然後維持一個小眾的熱度，最後到了 2025 終於熱度有明顯的上升。 （圖片擷取自 Google Trends。） 從這樣的圖表看來，Data Observability 仍是一個相對新的關鍵字，依然在發展中的階段。 如果我們將它跟其他關鍵字一起比較，會更能看出這件事。 誰在談論這個關鍵字？ 既然關鍵字熱度有在提升，那下一步來猜猜看是誰在推廣（炒作）這個關鍵字。 未看先猜，你的答案裡面一定有各種服務供應商對吧！ 確實如此，畢竟供應商的商業嗅覺是敏銳的，有能夠賣錢的關鍵字，當然要衝一波。 首先很早期喊出 Data Observability 的是 Monte Carlo Data 這間新興的服務供應商，目前可以找到比較早開始談資料可觀測性的文章，很多都來自這間公司。 當然，過去專注在 Monitoring 及 Metrics 的廠商也不會放過機會，因此像是 Datadog 也有跟上。以及本來就擁有包山包海各種解決方案的 IBM 也有一些動作。 （IBM 也有一個網頁在介紹 Data Observability。） Data 圈的一些知名服務供應商，例如 Splunk 就有網頁在介紹 Data Observability；而像是 Snowflake、Databricks、Cloudera，雖然他們自己沒有在談 Data Observability（多半是談 Observability），但倒是有一些想要搶 Data Observability 市場的新供應商，會嘗試將自己跟他們連結，例如 Acceldata 就有 “Data Observability and Support for Hadoop” 或 “Acceldata Data Observability for Snowflake Optimization” 這樣的文章。...

前言 嗨，大家好，我是艦長。 歡迎來到系列文的第 7 篇。過去 6 篇，我鋪了很多梗，讓大家可以更多認識軟體圈與 Data 圈的差異，點出原來 Data 圈關心的產品就是 Data 本身。 這篇文我們繼續拉回一個不分軟體圈和 Data 圈的議題「為什麼我們需要可觀測性？」 軟體圈有監控，但還是會發生客戶比你更早打電話來反應：「欸，你們的服務，今天是不是怪怪的？」 而 Data 圈也同樣有做資料監控，可是 Data User 還是會跑來跟你說：「欸，這份報表的數字怪怪的喔！」 所以到底是為什麼，明明我們已經有做了許多努力，卻無法解決品質問題？ 監控：見樹不見林的被動查核 前一篇文章中，我們有談到資料工程、資料監控。我覺得其實工程與監控這兩者都是基礎建設，也就是本來就該做的基本任務。 你本來就需要資料工程搭建資料管線去處理 Data，你的資料管線本來就該有基本的監控、告警與日誌功能。同樣你寫的軟體與線上服務，本來就該做好應有的 Error handling、Log 及監控告警等。 然而過去以來我們多半都是用一種「被動」的態度在處理「監控」。 因為有了 A，所以要加上 B 監控。 因為發生了 C，所以要加上 D 監控。 因為老闆說要 E，所以加上 F 監控。 也就是被動的檢核，「基於已知的問題，設定規則來檢查」。 並不是說監控（被動的檢核）就沒有用處，它當然很有用，它能幫我們發現與紀錄一些明確的問題，不然為什麼大家要在各種任務上，建立各種檢核表、SOP、檢核點。但它也有所侷限，容易形成一種局部、單點的查核。 可觀測性：提升系統資訊透明度的主動思維 而本系列文想要介紹的「資料可觀測性（Data Observability）」，則是受到近年（有人說是約 2010 年）開始在 IT 圈浮出水面之關鍵字「可觀測性（Observability）」的影響，約於 2019 年開始有人談論的題目。 有些文章會將可觀測性定義為，建立一套機制，讓我們可以透過主動觀測目標系統的「外部輸出」（例如：Logs, Metrics, Traces），以此有效的推斷、理解該系統的「內部狀態」，並且除錯那些「未知的問題」。 （謎之音：怎麼聽起來有點玄？） 我覺得這個定義點出「可觀測性（Observability）」最主要的重點是，讓我們建立一種「主動觀測」的思維。而這與 DevOps 提倡的提升「資訊透明度」是相符合的。 也就是過去我們也有做監控、有收集 Log、收集 Metrics，但是我們並沒有主動的去運用這些「監控資料」。 而自從進入可觀測性 1.0 的時代之後，我們開始對「監控」加入了主動性，即是我們不只做過去的那些收集 Logs、收集 Metrics、設立告警 Rules 的基本建設。我們還加上 Traces，並且讓這所有的「監控資料」串連並關聯在一起供隨時查閱。...

前言 大家好，我是艦長。 如同前幾篇文章鋪的梗，既然 Data User 最在意的就是 Data，而且會非常重視資料品質，甚至被逼到在使用 Data 之前，不得不自己再檢查一次品質、再做一次資料清洗。那麼顯然這是一個老問題，那麼針對老問題過去是不是已經有做了什麼事嘗試解決它呢？ 前人都種了哪些樹？ 在 Data 圈也有發展許多關於 Data 的方法論與實踐，其中與資料品質有關的至少有四個關鍵字。 資料工程 Data Engineering：建構穩定、高效的 Data Pipeline，是重要的 Data 基礎工程。好比上一篇文章中的淨水廠及自來水管線。 資料監控 Data Monitoring：確保 Data infra、Data Pipeline 及相關流程的正常運行，設置特定的規則與告警規則，自動偵測資料的變動、偏差與異常。用比喻來說，可以想像是在水系統中的各處設置了多個檢測站定時觀測水壓、水質與水量等多項指標。 資料品質 Data Quality：遵循一套規範及方法論，定義品質標準，去定義、衡量與改善 Data 本身的品質。如同政府機關設立了一份飲用水水質標準，定義吻合什麼品質標準的水才能作為飲用水。 資料治理 Data Governance：遵循一套規範及方法論，為企業建立管理 Data 的規範、政策、流程與權責。這就像是成立一個水資源管理局，制定用水規範、權責劃分與安全政策，甚至前一項比喻的飲用水之水質標準就是由這裡制定的。 關鍵字 內容 比喻 資料工程 (Data Engineering) 建構穩定、高效的 Data Pipeline，是重要的 Data 基礎工程。 淨水廠及自來水管線。 資料監控 (Data Monitoring) 確保 Data infra、Data Pipeline 及相關流程的正常運行，並設置特定的規則與警報，自動偵測資料的變動、偏差與異常。 在水系統中的各處設置了多個檢測站定時觀測水壓、水質與水量等多項指標。 資料品質 (Data Quality) 遵循一套規範及方法論，去定義、衡量與改善 Data 本身的品質。 政府機關設立飲用水水質標準，定義吻合什麼品質標準的水才能作為飲用水。 資料治理 (Data Governance) 遵循一套規範及方法論，為企業建立管理 Data 的規範、政策、流程與權責。 成立一個水資源管理局，制定用水規範、權責劃分與安全政策。 從這四項 Data 圈經常可聽見的關鍵字，不難發現 Data 圈過去已經有從多個層面嘗試做很多事情。...