Cheng Wei Chen | 艦長

很高興的，再次看見有認識的社群朋友出書，也很榮幸能為其書籍撰寫推薦序，當然要特別留下一篇文字作為紀念，並且幫忙推銷一下！ 畢竟這年頭，還願意扎扎實實寫書的人真的是越來越少了，任何願意將自己的經驗、知識轉化成文字，集結成書的人，都是令人尊敬的勇者！ 這次要分享的是台灣獲得 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 圈過去已經有從多個層面嘗試做很多事情。...

前言 大家好，我是艦長。 系列文連續鋪梗已經進入第五篇了，在上一篇我們比較了軟體圈與 Data 圈在看待 Data 時的根本差異，這一篇我們繼續聊 Data，用一個經典的比喻，來跟大家聊聊：為什麼想要取得高品質的 Data，是一件如此困難的事情？ 如何取得一杯乾淨的水 在 Data 圈，為了說明資料品質，有一個常見的比喻——「如何取得一杯乾淨的水」。 想像一下，如果我想要實現水龍頭一打開就能取得一杯可以直接生飲的水，我該怎麼做才好？ （謎之音：那就先裝一台 XX 牌高級濾水器不就好了 XD） 我知道一定有人會吐嘲說還不簡單，就裝一台濾水器不就好了，只要錢夠多，你要裝多高級的濾水器都行。誒，你這樣說也沒有錯啦，但這樣我這比喻故事就說不下去了 XDDDD 所以讓我修正一下問題——從水源上游開始一直到位於最下游為止，如果想要讓不同位置、不同用途的人，都可以一打開水龍頭就取得他所需的水，我們該怎麼做才好？ 好了，這次多了一些條件： 我們需要照顧從上游、中游到下游，於不同位置取水者的需求。 不同的人，對於水的需求（要求）不一定相同。 （好啦，我知道如果嚴謹討論，這些條件還是不夠完善，但就先放我一馬？） 如果大家有學過自然科學，或帶小孩去參加科博館之類的活動，其實多少都概略知道現代人的自來水系統。 水源來自上游的集水區，例如水庫。 接著水會被送到淨水廠。 經過淨水廠處理過的水，被送入自來水公司的地下管線。 最後，才進入各建築物的水系統，可以一開水龍頭就取水。 當然，現在家家戶戶還會自己加裝濾水器，做到打開濾水器的出水口就能直接飲用。 這整趟水系統，就像是 Data 圈處理 Data 的歷程： 集水區：即是各式各樣的 Data Source，是我們收集、累積、儲存 Source Data 的地方。 淨水廠與自來水管線：則是我們各式各樣的 Data Pipeline，這些 Pipeline 不只是將 Data 從 A 搬到 B，同時就像淨水廠會有沈澱、過濾、消毒的步驟，Data 圈也會透過 Data Pipeline 對 Source Data 做資料清洗、轉換的動作，讓下游的 Data 更貼近 Data User 需要的模樣。 各建築物的水系統：經過處理後的 Data，依然會需要地方儲存（或暫存），甚至就像為了供應頂樓加蓋的那一戶人家有足夠的水壓，還要額外加裝加壓器，所以除了集水區的 Data infra，你也需要為了末端的 Data User 準備他們所需的 Data infra 與 Pipeline。 家家戶戶的濾水器：即便淨水廠已經幫我們清潔過一次自來水，但你依然不敢直接生飲對吧？因為你會懷疑水在自來水管線或自家建物水管的運輸過程中可能有受到污染；因此在 Data User 真正開始使用 Data 前，多半還要自己花費工夫再清理與轉換一次 Data，甚至要自己檢驗 Data 品質。 如果不是為了飲用，日常民生用途的水，我們可以接受使用水龍頭一打開的自來水；Data 也是如此，就像金融業之於錢，電商之於庫存，同樣都叫做 Data，但有些 Data 我們的要求就是比較高，要求數字一定要正確，反之在其他情境或用途，就不一定需要這麼高的標準。 透過前面的比喻，大家應該都能理解我想要表達的內容。...

軟體圈與 Data 圈眼中的 Data 大家好，我是艦長。 在前兩篇文章的鋪梗中，我分別從軟體圈與 Data 圈的視角，分享了兩個圈子各自 User 關心的產品重點。 這一篇繼續延續鋪梗，我想把這兩個視角並陳比較，這兩個圈子在面對「Data」這件事時，有什麼差異。 話不多說，直接上表格。 關注點 Data 圈視角 軟體圈視角 產品 Data is the Product Software is the Product 產品內容 資料、報表、數據集本身 應用程式、軟體功能 資料準確性 絕對要求，是產品的核心價值 確保輸入/輸出結果正確即可 資料時效性 極度重視，直接影響資料分析價值 依功能需求而定，可接受快取延遲 資料結構 重視其清晰度與一致性 屬於後端實作細節，可接受各種妥協 就如上一篇文章說的，對於 Data User 而言，Data 本身就是產品；但對於軟體圈來說，很多時候 Data 只是軟體操作過程中的一次輸入與輸出。 因此對於 Data User 而言，Data 當然必須是又快、又好，最好還能又便宜。因為他所需要的就是那個 Data 本身，因此對於 Data 的準確性、時效性、完整性、可性度的要求就會很高。 而對於軟體圈而言，Data 就像是做料理過程中必須使用的部分食材或料理工序，它只佔了整道菜餚（使用者體驗）的一部分而已。所以食材可以很醜，例如 Table column name 是按編號建立的 col1、col2、col3，反正最終端上桌的菜餚，客人也看不出原貌；食材可以不新鮮，好比鮮度不夠的魚就用油炸處理，鮮度不夠的 Data，只要在 UI 上標示最多只能查詢前一天的消費紀錄。 小結 第四篇只是做一個簡單的比較，所以文章比較短。 從前面的比較中，可以看到不同圈子對待 Data 的方式不同。一個將 Data 視為必須精雕細琢的藝術品；另一個只是將 Data 視為達成功能的原料之一。...