資料中心筆記 #0:在變得具體之前

資料中心筆記 #0:在變得具體之前
Photo by Med Badr Chemmaoui / Unsplash

目標要做資料中心,一開始我不是很能夠想像這件事該長成什麼樣子,有很多疑問需要找到答案。

做到什麼程度算是資料中心? 我們期待它能解決什麼、幫助到誰? 它是不是應該包含一套接收資料的方法、能儲存大量資料的資料庫、提供資料服務的能力?  
那麼,它是一個平台嗎?該用什麼技術?有哪些其實現在不需要?又該怎麼做,才能保留未來需要的彈性?

這些問題在當下其實都沒有辦法很快有肯定又具體的答案。好像每一個點都應該被考慮到,但同時又覺得過於理想。那段時間,我甚至開始嘗試透過與 AI 的對話,把模糊的想法拆解成可以被檢視的問題。它沒有辦法替我做決定,但確實加速了我理解自己在問什麼。

只是,在理解問題的過程,即使把想法轉化輸出成一張張架構圖,進展卻不是太明顯,反而有一種腳步浮浮的、始終沒踩在地上的感覺,沒有讓事情真正往前走,我們仍然缺少可以被驗證的起點。

在這樣的狀態下,老闆很快地拋出先做個 POC 的想法,把資料拉進來看看,先驗證價值,再決定如何往下走。

現在回頭看,其實是一個很關鍵的引導,它讓想像的目標被驗證、被修正,逐漸轉化成具體,對我而言,是一次「以終為始」的實踐。


POC 的起點


POC 的做法很直覺。我們沒有先設計完整的系統,也沒有急著定義什麼叫標準資料架構,而是選擇用最直接、甚至手動的方式,把能取得的各類資料先匯進資料庫,用簡單的視覺化工具快速做分析。

目的很單純:看看這些資料,能不能真的回答問題。

在這個過程中,我所扮演的角色,是把方向轉成一個個可以實際嘗試的技術行為。過程並不優雅,也談不上完整,但事情開始變得具體。因為資料真的開始回應問題。

在反覆驗證過程中,我們慢慢知道哪些事情值得投入、應該優先投入。


為什麼要從這裡開始寫

這段「變得具體之前」的時期,其實影響了後來許多決定。

很多後來看起來理所當然的選擇,都是從那些不成熟、不完整、甚至有點混亂的嘗試中慢慢長出來的。如果只談後面的架構與成果,很容易讓整個過程看起來好像一開始就知道該怎麼做。

寫下這個系列,是想把那段還在摸索、還在修正的時間也留下來。
真正開始讓一切變清楚的,除了那些反覆的對話討論和修修改改的架構圖,更是資料被拉進來分析回答問題的那一刻。

自那一刻起,我們也就必須開始決定,這個資料中心要長成什麼樣子。

Read more

筆記 | 自架 Ghost 的 SMTP 設定

筆記 | 自架 Ghost 的 SMTP 設定

部落格荒廢了好一段時間,近期終於想用手機登入管理介面留下些草稿,突然發現無法登入,登入鈕下方出現了如下的一段訊息 EmailError: Failed to send email. Please check your site configuration and try again. 結論先行,原因是我安裝的 ghost 版本,在首次使用新裝置登入時需要 2FA (二階段驗證),也就是說,除了帳號密碼登入之外,還會有一層驗證機制,而這層驗證機制需要輸入 6 碼驗證碼 (Ghost 站台發給登入者註冊信箱的 mail 會提供)。我當時建置 Ghost 時認為自己不會發送電子報,就忽略了 SMTP 的設定,導致 Ghost 站台不能正常發信,在配置好 SMTP 設定後,從新裝置就能正常登入了。 前一篇文章提到我的 Ghost 是架設在

By Jo
部落格遷移紀錄

部落格遷移紀錄

是的,又搬家了。 這次搬家像是一種重新開始,遷移的範圍稍微大些,大致上有三段變動: * 從功能豐富的 WordPress 到簡潔高效的 Ghost * 從 SugarHosts 搬遷到 Google Cloud Platform (GCP),最後搬移到 zeabur Wordpress 的功能非常豐富,只是我使用到的部分極少,總想找個簡潔的服務使用,但忙碌的工作很快就澆熄了動力。一次在輸出小組群組中的討論,注意到 Ghost 這個部落格平台,試裝操作看看,體驗還不賴,想著我的文章數也很少 (心虛),就搬吧! 推進這個改變的契機,一部分也來自於 SugarHosts 自 2024 年底在網路社群中的討論,其中也包含了客服過久沒有回應的議題,SugarHosts 的價格真的很有吸引力,只是客服回應效率突然的落差,讓我開始擔心這是否對影響到部落格,開始思考搬家的可能,實際上身邊的朋友也愈來愈多人遇到類似情況,甚至站台無法再使用,措手不及使得只能使用較早期的備份來拯救文章。 我在年假期間利用 GCP 的試用額度來架設

By Jo
筆記 | Ubuntu 掛載磁碟

筆記 | Ubuntu 掛載磁碟

最近在 GCP 試玩 Compute Engine (VM),建立時另外新增了一顆磁碟,實際運行了才發現,原來需要自行掛載,記錄執行的指令與過程。 以 Ubuntu 22.04 為例 (多數的 Linux 應該也可以使用) 確認新增的磁碟是否存在 lsblk 大多情況應該會看到新的磁碟還沒有掛載任何分區 格式化 (如果硬碟還沒有格式化) sudo mkfs.ext4 /dev/sdb 配置自動掛載 取得新磁碟的 UUID sudo blkid /dev/sdb 一般會顯示類似以下的結果 /dev/sdb: UUID="一串由-符號串接的英數字" BLOCK_SIZE="4096" TYPE="ext4&

By Jo
筆記 | PostgreSQL v12 CTEs 行為改變

筆記 | PostgreSQL v12 CTEs 行為改變

前段時間,工作環境將 PostgreSQL v10 升級到 v15,升級後發現報表的執行效率從 1 秒變成了 2 分多鐘,也剛好變因太多,排查了很多項後才開始面對 SQL 執行計畫,同一段 SQL v10 跟 v15 有很大的差別,許多人花了一番功夫調整,速度才回到水準,接著進一步從調整方向的線索,再爬網路文章,才發現原來在 PostgreSQL v12 有一項對我們來說蠻重要的改變:CTEs 行為改變。 過去經驗裡,SQL 使用 CTE (Common Table Expression) 能將一段查詢的結果暫存起來,在主查詢語句中使用,能有提升查詢效率的效果 例如: WITH temp AS ( SELECT col1, col2, col3 FROM

By Jo