Jenkinsfile 不是 Groovy:CPS、序列化與沙箱
· tech · 約 6 分鐘 · 📚 Jenkins 學習筆記 #9
這個系列到目前為止給過三次同一個建議:Jenkinsfile 只做編排,邏輯放到 shell 腳本或 src/ 的 class 裡。 但我給的理由一直都很軟——好讀(半夜看它的人不一定會 Groovy…
Tech
Multibranch 與 PR 觸發:讓每個分支都有自己的 pipeline
· tech · 約 11 分鐘 · 📚 Jenkins 學習筆記 #8
前面七篇談的都是「一條 pipeline」。但真實的 repo 從來不只有一條路:main 上有人在合、三個 feature branch 在跑、還有兩個 PR 等著 review。 這篇處理的就是這…
Shared Library:把十份幾乎一樣的 Jenkinsfile,變成公司資產
· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #7
第 2 篇的結論是:把 pipeline 寫成程式碼、放進 repo。這件事在一個專案上是純粹的勝利,但當公司有十個、三十個專案之後,會長出一個新問題——十份幾乎一樣、但又不完全一樣的 Jenkins…
憑證管理:機密怎麼進 pipeline,又不會漏出去
· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #6
第 2 篇的結論是:pipeline 要寫成程式碼、進 git、讓每個人都能 review。這是整個系列的立場,但它有一個必須同時付的代價——這條路上的每一行,所有能讀這個 repo 的人都看得到。 …
進階 pipeline:平行、條件、失敗處理與那個很貴的人工關卡
· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #5
前面四篇處理的是「在哪跑」與「東西放哪」。這一篇回到 Jenkinsfile 本身:同樣一條會動的 pipeline,怎麼讓它跑得快、失敗得清楚、而且不會在半夜卡住一台機器。 這批東西的共同點是:它們…
Workspace 與 Artifact:build 出來的東西去哪了
· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #4
上一篇解決了「在哪台機器上跑」。這一篇往下挖一層:跑起來之後,檔案到底放在哪、留多久、誰看得到。 這聽起來很枝微末節,但它其實是整個系列主軸裡「可重現」最常破功的地方——而且破得很安靜:你的 CI 一…
Controller 與 Agent:工作到底在哪台機器上跑
· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #3
上一篇那份 Jenkinsfile 裡有一行 sh './scripts/ci-build.sh'。它到底在哪台機器上執行? 這個問題聽起來很基本,但它決定了三件事:你的 build 要等多久、失敗時…
第一個 Jenkinsfile:pipeline as code 為什麼贏過 UI 點按鈕
· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #2
上一篇最後那份 Jenkinsfile 只有二十行,語法簡單到不需要解釋。但我還是要為它寫一整篇——因為這二十行真正的價值不在語法,而在它躺在哪裡。 同一個 build,你可以在 Jenkins 的 …
Jenkins 是什麼:CI 不是「有跑測試」,是「頻繁合回主幹」
· tech · 約 13 分鐘 · 📚 Jenkins 學習筆記 #1
大部分人第一次碰 Jenkins,情境都差不多:公司有一台跑很久的 Jenkins,你要在上面「加一個 job」。點進去、複製隔壁專案的設定、改幾個欄位、按存檔——會動了,收工。這樣用了兩年,你會很熟…
領導力 - 願景
· tech · 約 7 分鐘 · 📚 成為 Tech Leader 讀書筆記 #8
創新篇走到這裡:拆了牆、學會看見自己、養起了點子流。但還剩最後一個問題——點子流有了,誰決定它流往哪裡? 一個團隊可以點子很多、討論很熱,但每個點子指向不同方向——這時候點子多反而是內耗。這章的答案是…
領導力 - 發想力
· tech · 約 6 分鐘 · 📚 成為 Tech Leader 讀書筆記 #7
前面談過擋住創新的三道牆,也談過用日記拆掉第一道牆——但牆拆掉之後呢?點子要從哪裡來? 這章給的答案是:發想力(idea power)是一種可以練的技能,不是天分。而且更反直覺的是——Leader 對…
責任的保費:AI 不收,也不賠
· tech · 約 9 分鐘 · 📚 帶 AI 的手藝(2026) #4
這篇的起點是一個樸素到近乎廢話的觀察:僱一個員工,他會負責,所以責任不(全)在你身上;用一個 AI,責任百分之百在你身上。第一篇把它叫做分流與全反射。但往下多想一步,它會裂開成一個更大的問題——雇用,…
看板上的頸:工具怎麼設計人的責任——兩個開源專案的對照稽核
· tech · 約 11 分鐘 · 📚 帶 AI 的手藝(2026) #3
第一篇立了模型:AI 吃寬層,人守頸口。第二篇把模型丟進事故現場驗證。這一篇看工具——因為 2026 年的工程師不是在白紙上跟 AI 協作,是在一堆新工具裡:agent 看板、多 agent 編排、s…
頸上有時鐘:事故中的 AI——重播一場毒藥訊息事故
· tech · 約 12 分鐘 · 📚 帶 AI 的手藝(2026) #2
上一篇講了漏斗:AI 吃掉寬層的量,人守住頸口的責任。這一篇把漏斗搬到它最極端的測試場——事故。事故是頸上有時鐘的場景:主播在罵、營運在催,而你必須在資訊不全的情況下做決定。AI 不能替你決定要不要在…
責任漏斗:AI 能做掉九成的事,為什麼剩下的一成是你
· tech · 約 6 分鐘 · 📚 帶 AI 的手藝(2026) #1
寫完 GitCrisp 和 部落格產線 兩篇之後,讀者最自然的下一個問題是:如果 AI 能做掉這麼多事,那你還剩什麼? 我的答案是一個形狀:漏斗。工作的量,大部分真的可以交給 AI——code、測試、…
這個部落格本身,就是一個作品:把寫作做成一條產線
· tech · 約 5 分鐘
寫了 旅遊分帳 和 GitCrisp 的介紹之後,發現漏了一個最常被使用的作品——你現在正在看的這個網站。它不是「架個 blog」:一百六十多篇文章、十幾個系列、一排小工具的背後,是一個 Astro …
GitCrisp:我和 AI 一起寫了一個 Git 桌面客戶端
· tech · 約 6 分鐘
GitCrisp 是一個桌面版的 Git 客戶端:視覺化 commit graph、逐 hunk staging、互動式 rebase、衝突解決介面、多倉庫管理,Python + PySide6(Qt…
Servers as Code:烘烤線畫在哪,決定你開機多快、改動多痛
· tech · 約 5 分鐘 · 📚 Infrastructure as Code 讀書筆記 #8
Stack 那層管的是「有哪些資源」;這篇往下鑽進資源裡最有內容物的那種——伺服器本身。一台 server 從開機到能服務,身上堆了一整疊東西,而 IaC 在這層要回答兩個問題:這疊東西什麼時候放上去…
Stack 與環境:staging 不該是另一份 code,是同一份的另一個 instance
· tech · 約 5 分鐘 · 📚 Infrastructure as Code 讀書筆記 #7
進入書的第二部分:stack。前面講切割時一直在說「一個 stack」怎樣怎樣,這篇先把這個詞站穩,再處理它最日常的應用場景——同一包基礎設施,要生出 dev、staging、prod 好幾份。這件事…
小而簡單的元件:爆炸半徑決定你敢不敢改
· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #6
三個核心實踐的最後一個。上一篇說變更批次要小,這篇補上它的前提:批次小得起來,元件先要小——如果整個系統是一包巨大的 stack,再小的改動也會被迫帶著整包一起上路。這章講的就是怎麼把基礎設施切成「小…
持續測試與交付:品質來自快回饋,不是守關卡
· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #5
三個核心實踐的第二個。上一篇把一切變成程式碼之後,下一個問題自然是:程式碼會錯,怎麼知道這次變更是安全的?書的答案跟傳統直覺相反——不是在上線前設一道更嚴的關卡,而是把驗證拆碎、塞進工作的每一步。品質…
一切皆程式碼:宣告式寫終點,程序式寫路徑
· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #4
前三章鋪完為什麼、原則、平台,從這章開始進入三個核心實踐,第一個就是招牌:把所有東西定義成程式碼——不只伺服器,網路、pipeline、監控、權限,全部。好處書裡列得很整齊(可重用、一致、透明、可測試…
基礎設施平台:你家的雲,是真的雲嗎?
· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #3
前兩章講完 為什麼和原則,第三章回頭補一個地基問題:IaC 要有東西可以 code——你的定義檔寫得再漂亮,也要有一個收到 API 呼叫就能生出資源的平台在下面接著。這章就在講這個「動態基礎設施平台」…
雲時代基礎設施的原則:壞了就重建,可靠性來自軟體
· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #2
第一章說雲時代該擁抱變更,這章回答「憑什麼敢」。前提先翻轉:鐵器時代的可靠性是用錢買硬體——更貴的機器、雙電源、RAID、原廠保固;雲跑在海量便宜的 commodity 硬體上,供應商直白告訴你:任何…
Infrastructure as Code 是什麼?從「變更」的成本翻轉講起
· tech · 約 7 分鐘 · 📚 Infrastructure as Code 讀書筆記 #1
開一個新系列:讀 Kief Morris 的 Infrastructure as Code,用的是第三版(2025)——副標從第二版的 Dynamic Systems for the Cloud Ag…
旅遊分帳:把 Google Sheet 當後端,寫一個不會把帳弄丟的分帳工具
· tech · 約 6 分鐘
每次跟朋友出國,分帳都是同一個劇本:有人先墊機票、有人刷了租車、晚餐又是另一個人付——回國後對著一堆收據算「誰欠誰多少」,算到懷疑人生。市面上的分帳 App 不是要每個人都註冊帳號,就是要大家都裝同一…
維運中斷:殺死生產力的不是工作量,是被切碎的時間
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #17
On-call 那篇講「怎麼設計告警、誰值班」,Toil 那篇講「用 50% 護欄別讓維運吃光工程時間」。但這兩條之間,漏了一個每天都在發生、卻很少被當成問題來管的東西:中斷(interrupts)—…
生產就緒審查(PRR):SRE 憑什麼接手一個服務
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #16
前面十五篇,講的幾乎都是「服務已經在線上了,怎麼讓它更可靠」——SLO、監控、postmortem、降級。但有一個更前面的問題一直沒問:一個新服務,憑什麼可以上線、憑什麼值得 SRE 接手扛 page…
關聯:從一個尖峰,點到那一行 log
· tech · 約 4 分鐘 · 📚 Grafana LGTM 可觀測性 #8
整個系列從第一篇的黃金路徑就一直押著一句:metric 看有沒有、trace 看在哪、log 看是什麼,由粗到細。但我一直跳過最關鍵的一步——這三格之間,到底怎麼「跳」過去?Tempo 那篇說「找 t…
Playbook 進階:變數、條件,與重新定義成功
· tech · 約 5 分鐘 · 📚 Ansible for DevOps 讀書筆記 #4
上一篇的 playbook 是死的:寫死的套件、寫死的路徑,只能打一種環境。第五章一口氣補上讓它活起來的所有機關——變數、條件、錯誤處理。內容很雜,但整理之後其實就三個主題:資料從哪來(變數、fact…
第一份 Playbook:把 shell 腳本翻譯成宣告式
· tech · 約 4 分鐘 · 📚 Ansible for DevOps 讀書筆記 #3
上一篇說膠帶貼到第二次就該轉正——這篇就是轉正手續。Playbook 說穿了只是「把 ad-hoc 指令寫進 YAML 檔案」,但書的第四章真正想教的,是一個世界觀的切換:腳本描述步驟,playboo…
Ansible ad-hoc:一行指令,管一群機器
· tech · 約 4 分鐘 · 📚 Ansible for DevOps 讀書筆記 #2
上一篇說 Ansible 第一天就能用——這篇就是「第一天」的實際內容。書的第二、三章其實在回答兩個很務實的問題:我要在哪裡練習?(答案:一個可以隨時砍掉重練的本機實驗場)以及還沒學 playbook…
Ansible 是什麼?從告別雪花伺服器講起
· tech · 約 5 分鐘 · 📚 Ansible for DevOps 讀書筆記 #1
每個維運過伺服器的人都經歷過這個循環:SSH 登入機器、改幾個設定、裝幾個套件、登出——三個月後沒有人記得那台機器上到底改過什麼。書裡把這種機器叫做 snowflake server(雪花伺服器):每…
Re:如果真的重來
· tech · 約 7 分鐘 · 📚 Re:從零開始做直播代購電商平台 #21
這個系列從一則留言的旅程開始,寫了二十章。終章不新增任何架構,只做四件事:交代結局、講完最後一個月、把三個寫到中段才浮現的體悟收起來,然後回答書名的問題——如果真的重來,我會改什麼。 19 講過那一天…
平行世界:如果變成 SaaS
· tech · 約 11 分鐘 · 📚 Re:從零開始做直播代購電商平台 #20
先交代一件前面十九章都沒說的事:當年我們每一個人,都是降薪進來的。降薪換的是一個承諾——現在做的直播代購平台只是第一站,真正要造的是一艘 SaaS 大船:把整套系統賣給每一個想做直播代購的商家。 船,…
三個人的微服務:暫停開發之後
· tech · 約 8 分鐘 · 📚 Re:從零開始做直播代購電商平台 #19
上一章結尾說,這個團隊的終點比所有人想的都近。這章從那一天講起。 某天,CTO 通知全部工程師:暫停開發。與第三方的合約要重新談;可能會走向資遣;他會去幫大家爭取多一點資源。 政治的細節留給終章,這章…
六個工程師,跑出二十個人的速度
· tech · 約 7 分鐘 · 📚 Re:從零開始做直播代購電商平台 #18
系統的故事,到上一章告一段落;剩下的章節要講的,是做出這個系統的人,和這一切是怎麼結束的。先回答一個最基本的問題:前面十七章的系統——FSM、三層訂單、金流事實表、一台 VM 的帝國——是誰做出來的?…
上傳容易,刪除難:圖片與資源的生命週期
· tech · 約 9 分鐘 · 📚 Re:從零開始做直播代購電商平台 #17
這章插一個看起來最不起眼的題目:商品圖。「不就是上傳檔案嗎」——這章會用一半的篇幅講上傳,另一半講一件難得多的事:刪除。上傳只要一個下午就能做完;刪除,是一輩子的事。 先看這條管線的真實使用場景,因為…
對帳:我們沒有做,為什麼帳還是對的
· tech · 約 7 分鐘 · 📚 Re:從零開始做直播代購電商平台 #16
這章在規劃裡叫「三本帳:庫存帳、訂單帳、金流帳」,本來要寫我們怎麼對帳。動筆前照慣例回去查證當年的實際做法,結果是:我們沒有做對帳。 系統裡沒有對帳排程、結束檔期不核帳、上線後也幾乎沒處理過錯帳。 一…
沒有 SRE 的年代:backend lead 的上線日記
· tech · 約 9 分鐘 · 📚 Re:從零開始做直播代購電商平台 #15
上一章講尖峰怎麼打;這一章講打仗的人。當年團隊沒有 SRE 這個職稱——身為 backend lead,infrastructure 的仗自然全落在我身上。這章是那段提心吊膽日子的日記:全部家當一台 …
開賣瞬間:主播喊完 key 的那三秒
· tech · 約 8 分鐘 · 📚 Re:從零開始做直播代購電商平台 #14
交易和營運的故事都寫完了,接下來幾章講的是貫穿全系統的事:尖峰、維運、對帳。先從所有直播電商的原點講起——主播喊完 key 的那三秒。這章有真實的數字、最痛的一次事故,和一條從被打爆一路通往「雲端菩薩…
風控與黑名單:不是逐客令,是信用體系
· tech · 約 6 分鐘 · 📚 Re:從零開始做直播代購電商平台 #13
先把攻擊模型講清楚。這個系統裡,留言喊單當場佔庫存、付款卻在檔期尾聲——中間隔著幾天的信任。惡意的玩法於是很簡單:喊單、佔住、不付。庫存被白佔最長一整週(檔期長度),真想買的客人搶不到,主播的貨卡在幽…
通知系統:兩個欄位、一支排程,和一通電話
· tech · 約 7 分鐘 · 📚 Re:從零開始做直播代購電商平台 #12
「通知系統」四個字在教科書裡的長相:一套 notification service、一組 message queue、模板引擎、多渠道 SDK、退避重試框架。這章要講的版本是:兩個欄位、一支排程掃描、…
優惠與金額:折扣算錯,比超賣還難查
· tech · 約 12 分鐘 · 📚 Re:從零開始做直播代購電商平台 #11
超賣會炸、金流會叫,折扣算錯不會有任何聲音——客人多付了 13 元不會知道,少收了 13 元你也不會知道,直到對帳那天一筆一筆挖。這章講優惠:規則怎麼收納、聰明演算法怎麼輸給主播的一句話、以及讓分攤永…
權限:誰能按哪顆按鈕——我們改了三次
· tech · 約 11 分鐘 · 📚 Re:從零開始做直播代購電商平台 #10
權限是我自己認證當年沒做好的部分之一:改了三次,每次都花了真實的時間,每次都只對了一半。有趣的是,把三次改版排開來看,它剛好走完了權限系統的經典演化路徑——所以這章與其說是懺悔,不如說是幫後人把路標插…
主播與營運後台:沒有一個叫「後台」的東西
· tech · 約 5 分鐘 · 📚 Re:從零開始做直播代購電商平台 #9
前八章寫的是交易的骨架:留言進來、庫存卡住、錢收好、貨出門。這章換一個視角——站在直播現場的人,看到的是什麼。講「後台」之前先劇透結論:這個系統裡沒有一個叫「後台」的東西,有的是一組角色介面,每個人打…
出貨前處理:賣的是承諾,出的是現實
· tech · 約 7 分鐘 · 📚 Re:從零開始做直播代購電商平台 #8
錢收完了,該出貨了。這章是系統與實體世界的交界——留言、庫存、金流都活在資料庫裡,但貨是真的紙箱、真的倉庫、真的宅配司機。也因此,這是全系列「系統邊界」劃得最有意識的一章:哪些歸系統管、哪些交給人,當…
Grafana 告警:從看見到行動
· tech · 約 5 分鐘 · 📚 Grafana LGTM 可觀測性 #7
這系列從第一篇就一直押著一句話——觀測的終點不是「看到」,是「行動」。前面六篇把「看到」講完了:三支柱怎麼存、怎麼查、怎麼進來。這篇補上最後那一哩、也是整個系列的 payoff——告警(Alertin…
第三方金流:教科書的三個坑,與一個沒有坑的地形
· tech · 約 6 分鐘 · 📚 Re:從零開始做直播代購電商平台 #7
上一章把單聚合成了三層,現在要收錢了。金流是這個系統第一次把「正確」交到別人手上——付款發生在銀行那邊,你只能透過不可靠的網路得知結果。教科書會警告你三個坑:通知會重複、會亂序、會根本不來。這章要講的…
購物車到訂單:被主播拔掉的狀態機
· tech · 約 8 分鐘 · 📚 Re:從零開始做直播代購電商平台 #6
交易主線的最後一站:單怎麼從購物車走到訂單。留言進了購物車、身分掛好了單、庫存卡住了不變量——這章把它們聚合成一筆可以付錢、可以出貨、可以開發票的東西。標題不是比喻:這個系統裡真的有一台狀態機,被主播…
庫存:不能超賣,是這個系統唯一的鐵律
· tech · 約 8 分鐘 · 📚 Re:從零開始做直播代購電商平台 #5
留言解析完、身分掛好單,主線走到心臟:庫存。這個系統的功能清單可以慢慢長,但只有一條規則從第一天就是鐵律——不能超賣。賣掉不存在的貨,是要一個一個跟客人道歉退款的。這章講當年怎麼守這條不變量、它被什麼…
身分與帳號:留言的那個人,到底是誰
· tech · 約 9 分鐘 · 📚 Re:從零開始做直播代購電商平台 #4
上一章的 FSM 解出了「誰買了什麼」——但那個「誰」,其實只是 FB 給的一串數字。他可能從來沒註冊過我們的平台,可能明天才會登入,可能永遠不會。而庫存現在就要卡給他。這章講全景裡我說「全系列最容易…
採集層:資料怎麼進來——OpenTelemetry 與 Alloy
· tech · 約 5 分鐘 · 📚 Grafana LGTM 可觀測性 #6
三支柱講完了,但有個前提一直被我跳過:訊號要先「進得來」,才有得看。第一篇資料流圖中間那格「採集層」,這篇把它拆開。兩個主角:OpenTelemetry(統一三種訊號的標準)與 Grafana All…
留言即下單:把聊天室變成下單通道
· tech · 約 13 分鐘 · 📚 Re:從零開始做直播代購電商平台 #3
全景和起手式鋪完,進主線第一戰:一則留言,怎麼變成一筆單。這章講「接進來」和「解析」兩段,佔庫存的攻防留給下一章。主角是把聊天室變成收銀機的那台有限狀態機——我們會直接讀它的程式碼。 留言來自三個源:…
起手式:五個元件與一條 CI/CD
· tech · 約 6 分鐘 · 📚 Re:從零開始做直播代購電商平台 #2
全景鋪完,講留言、庫存那些戰役之前,先把當年的武器庫攤開——因為後面每一章的取捨,都是在這套技術棧的邊界裡做的。團隊很小:3 個後端、3 個前端,偶爾發包給外包 1–2 位工程師。武器庫也很樸素:Po…
全景:留言下單的一筆訂單,會經過哪些系統
· tech · 約 6 分鐘 · 📚 Re:從零開始做直播代購電商平台 #1
這是一個新系列,也是這個部落格第一個戰爭故事。我在前公司實際做過一個直播代購電商平台——使用者看直播、在留言區打字下單,後面接著庫存、金流、物流一整條鏈。這系列不是回憶錄:我想帶著現在的功力(DDIA…
資料系統的未來:拆開的資料庫、Kappa,與端到端的正確性(完結)
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #12
終章。前面十一章把儲存、複製、分區、交易、共識、批次、串流一塊塊講完,Kleppmann 在這章把它們收攏成一個大膽的視角:別再把「資料庫」當成一個盒子——把它拆開。 而讀到這裡你會發現,這個「未來」…
串流:雙寫的陷阱、CDC,與流表二象性
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #11
批次處理「已經齊了」的資料;串流處理「一直來」的資料。這章很多地基我在別處鋪過了:log 與 offset 在 Kafka 系列、投遞保證在 delivery 那篇、視窗與 event time 在 …
批次處理:MapReduce 的精神、join 的兩條路,與不可變輸入的美德
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #10
Part II 在單一系統內把一致性守住了;Part III 的主題換成資料在系統之間流動——而最古老、也最可靠的流動方式,是批次(batch)。DDIA 講 MapReduce 的切入點很別緻:先講…
一致性與共識:linearizability、CAP 的誠實版,與全序廣播
· tech · 約 5 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #9
上一篇的結論是:任何單一節點的判斷都不可信,真相只能由多數決定。這章講的就是「多數怎麼安全地決定」——DDIA 全書的理論高潮。演算法細節(Raft、Paxos、Zab 怎麼投票換屆)我在 SRE 共…
分散式系統的麻煩:不可靠的網路、不可信的時鐘,與半死不活的節點
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #8
上一篇結尾埋了個鉤子:當系統跨到多台機器,連「鎖」和「驗證」本身都變得不可靠。這章就是那個「不可靠」的總清算——也是我認為全書最該精讀的一章。核心一句話:單機世界是確定性的,要嘛全好、要嘛全壞;分散式…
交易:快照隔離擋不住的 write skew,與可串行化的三條路
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #7
交易的地基我在 SQL 系列鋪過了:ACID 的重點是 I、髒讀/不可重複讀/幻讀三種怪事、四個隔離層級的光譜、MVCC 怎麼讀不擋寫——那些這篇不重複。DDIA Ch7 真正的加值在後半:兩個連「快…
分區:range 還是 hash、二級索引擺哪、以及怎麼重新平衡
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #6
複製是同一份資料放多台;分區(partitioning,也叫 sharding)是把資料切開,每台只放一部分——當資料量一台裝不下、或寫入 throughput 一台吃不消,這是唯一的出路。兩者幾乎總…
複製:單主、多主、無主,與延遲的三個怪象
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #5
進入 Part II,資料開始跨機器。第一招是複製(replication):同一份資料放多台,為的是三件事——一台掛了還能服務(高可用)、資料放得離使用者近(低延遲)、讀流量攤出去(擴讀)。如果資料…
追蹤與 Tempo:一個請求走過的路
· tech · 約 4 分鐘 · 📚 Grafana LGTM 可觀測性 #5
三支柱最後一個:traces。它補的是 metric 和 log 之間那個最關鍵的洞——「在哪一段?」 Metric 告訴你「checkout 慢」,但一個請求橫跨了八個服務,到底卡在哪一 hop?L…
編碼與演化:讓新舊程式碼,讀得懂彼此的資料
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #4
上一篇講資料怎麼放上磁碟,這篇講一個更容易被輕視的問題:資料寫出去時,是用什麼格式編碼的? 你可能覺得「JSON 就好了啊」——直到 schema 要改的那一天。這章的重量,來自兩個躲不掉的事實:資料…
日誌與 Loki:只索引 label,不索引全文
· tech · 約 4 分鐘 · 📚 Grafana LGTM 可觀測性 #4
三支柱第二個:logs。而 Loki 最該懂的一件事,是它一個很聰明、很省的設計選擇——它不像傳統 log 系統(ELK)那樣索引全文,而是「像 Prometheus 一樣只索引 label」。這個選…
儲存引擎:LSM-tree、B-tree,與欄式儲存
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #3
上一篇選好了資料模型,這篇往最底層鑽:資料庫到底怎麼把資料放上磁碟、又怎麼找回來? DDIA 這章從一個兩行 bash 的「全世界最簡單資料庫」開場——dbset 就是往檔案尾巴 append 一行,…
指標與 Prometheus:時序、pull、PromQL 與 cardinality 的坑
· tech · 約 5 分鐘 · 📚 Grafana LGTM 可觀測性 #3
三大支柱進第一個,也是骨幹:metrics。它是你「有沒有問題」的第一道防線,也是後面告警和 SLO 的底層數字。而 metrics 世界的事實標準,是 Prometheus。這篇講它的資料模型、為什…
Grafana:一塊玻璃,只查不存
· tech · 約 5 分鐘 · 📚 Grafana LGTM 可觀測性 #2
第一篇那張資料流圖,最右邊那格是 Grafana。這篇把它拆開——而理解 Grafana,其實只要抓住一句反直覺的話:它不存任何觀測資料,它只是一塊拿來「問」的玻璃。 想通這句,它的所有特性就都通了。…
可觀測性是什麼:三大支柱與 LGTM 全家桶
· tech · 約 5 分鐘 · 📚 Grafana LGTM 可觀測性 #1
一個系統可不可靠,先看你看不看得見它在幹嘛。這系列講 Grafana 的 LGTM 這套可觀測性工具怎麼把「看見」做到位。第一篇立好整個系列的框架:monitoring 和 observability…
Airflow 進階:Datasets、deferrable operators 與 executor 選型
· tech · 約 5 分鐘 · 📚 Airflow 學習筆記 #9
這篇講三個進階功能。它們看似無關,其實有個共同點:都在解 Airflow 某個「死板」或「浪費」——排程只認時間、sensor 佔著 slot 空等、worker 一刀切。三個都是選配,但每個都能讓你…
把它們兜成一個資料平台
· tech · 約 5 分鐘 · 📚 從 Infra 角度看資料工具 #9
前面八篇,一個一個工具看。這篇把它們兜成一個平台。而「兜」的方法,不是把七個工具的細節背起來——是抓住那條從第一篇就在講的軸:stateful ↔ stateless。這條軸一句話決定了每個工具在平台…
Kafka Connect:連接器的執行時
· tech · 約 5 分鐘 · 📚 從 Infra 角度看資料工具 #8
收尾 stateless 這一批的最後一個:Kafka Connect。它是一套專門在 Kafka 與外部系統(資料庫、S3、Elasticsearch)之間搬資料的框架——你不用每次都手寫消費者/生…
Pub/Sub vs Stream:Redis 版的訊息系統
· tech · 約 5 分鐘 · 📚 Redis 學習筆記 #12
Redis 也能當訊息系統,但它有兩套截然不同的東西,用錯就會莫名其妙掉訊息、或殺雞用牛刀:Pub/Sub(廣播,丟了就丟)和 Stream(留著的 log,像一台縮小版 Kafka)。這是整個 Re…
管線、交易與 Lua:省 RTT 與原子性
· tech · 約 4 分鐘 · 📚 Redis 學習筆記 #11
有三個東西常被混在一起,其實各解完全不同的問題:pipeline 解「網路來回太多」、MULTI/EXEC(交易)解「一組命令要一起執行不被插隊」、Lua 解「要原子、又要帶邏輯」。搞混它們,你會拿 …
Airflow 測試與部署:別讓一個 typo 弄垮整包 DAG
· tech · 約 7 分鐘 · 📚 Airflow 學習筆記 #8
DAG 寫好了、也可靠了,最後一哩是工程紀律:怎麼確定我的改動不會弄壞它,又怎麼把它安全送上 Production。 這篇講測試(把壞 DAG 擋在 merge 前)、部署(DAG 檔怎麼上環境、se…
Airflow 可靠性實戰:冪等、重試、SLA 與告警
· tech · 約 5 分鐘 · 📚 Airflow 學習筆記 #7
前面幾篇教你把 DAG 寫出來、排對區間。但 Production 的 DAG 是會在半夜出事的——來源系統延遲、網路抖一下、下游資料庫重啟。這篇講怎麼讓 DAG 扛得住失敗、能自己救、真救不了會大聲…
Redis Cluster:16384 個 slot 怎麼分片與擴縮
· tech · 約 5 分鐘 · 📚 Redis 學習筆記 #10
單執行緒那篇說過,一台 Redis 的瓶頸是記憶體與網路。當一台裝不下、或流量頂到單機上限,就要把資料分片(sharding)到多台——這就是 Redis Cluster。但它的分片方式很有個性:不用…
高可用:Sentinel 怎麼自動故障轉移
· tech · 約 5 分鐘 · 📚 Redis 學習筆記 #9
上一篇的主從複製給了你副本,但留了一個大洞:master 掛了,不會自動有人接手。 你得半夜爬起來,手動把某個 replica 升成 master、把其他 replica 改指向它、再叫所有客戶端換位…
主從複製:讀寫分離與複製延遲的怪現象
· tech · 約 4 分鐘 · 📚 Redis 學習筆記 #8
一台 Redis 再快也有記憶體與流量的上限,而且它一掛,資料就懸在半空。走向高可用的第一塊地基,就是主從複製(replication):一個 master 負責寫、若干 replica 各複製一份、…
Airflow:排程器、worker 與那個藏起來的狀態
· tech · 約 6 分鐘 · 📚 從 Infra 角度看資料工具 #7
上一篇埋了個伏筆:每個系統都有一塊逃不掉的狀態,認出它就掌握了命門。 Airflow 是這句話最好的示範。它表面上全是看似無狀態、可重啟的組件——scheduler、webserver、worker,…
分散式鎖:從 SETNX 到 Redlock,與那場著名的爭議
· tech · 約 5 分鐘 · 📚 Redis 學習筆記 #7
多個行程、多台機器要搶同一個資源(同一時間只准一個人扣庫存、跑一個排程),就需要一把分散式鎖。Redis 因為快又原子,常被拿來當這把鎖。但這是個「看起來三行就能寫完、其實坑深到見底」的題目——一路踩…
Spark:短命 executor 的彈性運算
· tech · 約 5 分鐘 · 📚 從 Infra 角度看資料工具 #6
前三篇(Kafka、Redis、RabbitMQ)都在光譜的 stateful 那一端——狀態綁在自己的磁碟或記憶體,擴縮要搬資料、故障要救資料。這篇翻到光譜的另一端:Spark,系列第一個 stat…
打包與部署:Helm 與 Kustomize
· tech · 約 6 分鐘 · 📚 Kubernetes 學習筆記 #14
前面每一篇都在教你寫 YAML,但實務有個逃不掉的痛:同一個 app 要上 Development、Staging、Production,而三個環境九成的 YAML 一模一樣,只有幾個地方不同——副本…
故障排除:Pod、Node、Control Plane 怎麼查
· tech · 約 7 分鐘 · 📚 Kubernetes 學習筆記 #13
CKA 佔比最高的一塊是故障排除(30%),但它其實不是新知識——它是把前面整個系列串起來的能力。排障最忌諱用猜的、亂試一通。真正的心法只有一句:沿著 Pod 的生命週期,一關一關問「它卡在哪」——因…
叢集管理:kubeadm、etcd 備份、升級
· tech · 約 5 分鐘 · 📚 Kubernetes 學習筆記 #12
前面十一篇都站在「用叢集」的位置。這篇換到「建與養叢集」的位置——CKA 佔 25% 的 Cluster Architecture 裡最硬的 ops 活。三件事貫穿一個管理員的一生:怎麼把一堆機器變成…
RBAC:誰能對叢集做什麼
· tech · 約 6 分鐘 · 📚 Kubernetes 學習筆記 #11
前面十篇都在讓東西「跑起來、連得到」。這篇換一個維度:誰有權對叢集下命令? 一個 kubectl delete 打進 API Server,它憑什麼知道你是誰、又憑什麼准你刪?這是 RBAC(Role…
NetworkPolicy 與 CNI:Pod 之間的防火牆
· tech · 約 6 分鐘 · 📚 Kubernetes 學習筆記 #10
Service 與 Ingress 講的是「流量怎麼找到服務」,但底下有個更基本、也更容易被忽略的問題:Pod 跟 Pod 之間,預設能不能互通? 答案會嚇到很多人——預設全通,任何一顆 Pod 都連…
Ingress 與叢集 DNS:一個入口進來、一個名字相認
· tech · 約 6 分鐘 · 📚 Kubernetes 學習筆記 #9
第四篇給了短命 Pod 一個固定門牌 Service,但留了兩個尾巴:一是「外面怎麼用一個入口進來、再按網址分流到不同服務?」——那張對外類型圖裡最上面的 Ingress;二是叢集內服務彼此互打時,那…
進階排程:讓 Pod 去對的 node
· tech · 約 8 分鐘 · 📚 Kubernetes 學習筆記 #7
第二篇講過 Scheduler 幫 Pending 的 Pod 挑 node 分兩步:先過濾(裝得下、規則允許)、再評分(挑最佳)。 那時我說「過濾與評分背後的旋鈕之後專門一篇講」——就是這篇。預設 …
K8s 儲存:Volume、PV/PVC 與 StatefulSet
· tech · 約 5 分鐘 · 📚 Kubernetes 學習筆記 #6
Pod 是短命、可拋的——自我修復隨時把它換一個。但有些東西死了不能跟著消失:資料。而容器的檔案系統天生是暫時的(ephemeral):pod 一被重排、容器一重啟,寫在裡面的檔案就沒了。所以 K8s…
快取三大災難:穿透、擊穿、雪崩,與正確解法
· tech · 約 3 分鐘 · 📚 Redis 學習筆記 #6
把 Redis 當快取,最經典的模式是 cache-aside(旁路快取):讀取先查 cache,命中就回傳、沒命中(miss)才查資料庫,再把結果回填進 cache。平常運作得很好——直到某些情況下…
RabbitMQ:訊息 broker 的叢集與流控
· tech · 約 5 分鐘 · 📚 從 Infra 角度看資料工具 #5
收尾「有狀態的重量級」這一批,第三個是 RabbitMQ。它跟 Kafka 都是訊息中介,但 infra 形狀差很多,而差別可以濃縮成一個字:Kafka 是 log,RabbitMQ 是 queue。…
ConfigMap 與 Secret:把設定和機密從映像檔裡拆出來
· tech · 約 5 分鐘 · 📚 Kubernetes 學習筆記 #5
前面幾篇,你已經能把一個 app 部署、對外服務了。但真實的 app 還缺一塊:設定——資料庫位址、feature flag,還有密碼、API key、憑證。這些東西有一條鐵律:不該寫死在映像檔或程式…
Redis:記憶體為界的有狀態服務
· tech · 約 4 分鐘 · 📚 從 Infra 角度看資料工具 #4
第二個有狀態的重量級是 Redis,而它跟 上一篇的 Kafka 剛好是一組完美對照:Kafka 磁碟為王,Redis 記憶體為界。兩者都有狀態,但體檢表第②題「狀態放哪」的答案不同——一個在磁碟、一…
Kafka:磁碟為王的有狀態叢集
· tech · 約 4 分鐘 · 📚 從 Infra 角度看資料工具 #3
進入有狀態的重量級,第一個是 Kafka。用體檢表看它,一切都從第②題「狀態」展開——Kafka 的資料(那條可重播的 log)不是抽象概念,它實實在在躺在 broker 的磁碟上。這一個事實,決定了…
Kubernetes:所有東西跑的底座,它自己怎麼站穩
· tech · 約 6 分鐘 · 📚 從 Infra 角度看資料工具 #2
這系列第一個要體檢的,是 Kubernetes——但它很特殊:別的工具都跑在它上面。它是底座,所以它自己的可靠度,就是後面 Kafka、Spark、Redis 全部的地基。用上一篇的體檢表看它,會發現…
從 Infra 角度看一個工具,要問哪些問題
· tech · 約 3 分鐘 · 📚 從 Infra 角度看資料工具 #1
學一個工具、和把它放進 Production,是兩種完全不同的問題。學的時候你問「這個 API 怎麼用、這個概念是什麼」;上 Production 時你問的是另一組問題——它會怎麼掛?怎麼長大?半夜壞…
Redis 的過期與淘汰:TTL、惰性刪除與 maxmemory 政策
· tech · 約 4 分鐘 · 📚 Redis 學習筆記 #5
把 Redis 當快取,遲早會碰到兩個問題:設了 TTL 的 key 到期後怎麼被清掉? 以及 記憶體滿了會怎樣? 這兩件事常被混為一談,其實是兩回事——前者是過期(expiration):「這個 k…
Redis 持久化:RDB 快照 vs AOF 日誌,資料到底會不會丟
· tech · 約 5 分鐘 · 📚 Redis 學習筆記 #4
「Redis 是記憶體資料庫,一斷電資料就全沒了」——這句話半對半錯。對的是它主要活在記憶體;錯的是它其實有持久化,能把資料寫到磁碟、重啟後還原。只是它的持久化語意比傳統資料庫弱,你得懂才用得對。Re…
可靠的 cron:最單純的定時任務,一分散就變難
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #15
cron 大概是最單純的一種基礎設施:時間到,跑一個任務。單機上寫過 crontab 的人都覺得它理所當然。但只要加上兩個字——「可靠」(那台機器掛了,任務還是得照跑),它就從最簡單的東西,一夕變成一…
Redis 單執行緒為什麼反而快?——以及 O(N) 命令的地雷
· tech · 約 4 分鐘 · 📚 Redis 學習筆記 #3
第一篇說 Redis 快的原因之一是「單執行緒 + 免鎖」。這聽起來很反直覺——單執行緒不是慢嗎? 這篇就把這件事講透:為什麼單執行緒反而快、它換來什麼,以及它一體兩面的代價——一個慢命令會卡住所有人…
Redis 的靈魂:五大資料結構 + 進階武器
· tech · 約 4 分鐘 · 📚 Redis 學習筆記 #2
上一篇說 Redis 的靈魂是「資料結構」——那這篇就把工具箱打開。Redis 用得好不好,九成看你會不會選對結構:選對了,一個排行榜三行命令搞定;選錯了,你會用一堆 GET/SET 在應用端硬幹本來…
Redis 是什麼:不只是快取,是記憶體資料結構伺服器
· tech · 約 5 分鐘 · 📚 Redis 學習筆記 #1
大多數人第一次認識 Redis,都是把它當「快取」——把資料庫查詢的結果丟進去、下次直接拿。這沒錯,但也把它看小了。Redis 的本質是一台記憶體資料結構伺服器(in-memory data stru…
Apache ZooKeeper:分散式系統的協調核心
· tech · 約 6 分鐘
上一篇共識帶到 Zab 是 ZooKeeper 的引擎,但 ZooKeeper 本身值得單獨講一篇。它是分散式系統的協調核心(coordination service):你很少直接用它,卻天天間接依賴…
SRE 空降一間『什麼都自建』的公司,前 90 天怎麼站穩
· tech · 約 7 分鐘 · 📚 Google SRE 讀書筆記 #14.5
換工作最刺激的一種,是加入一間幾乎什麼都自建的公司:沒有現成的雲服務、連 Stack Overflow 都幫不上忙——因為這裡的基礎設施、部署工具,全世界只有這一家在用。你過去累積的「某某工具怎麼設定…
分散式共識:一群會掛的機器,如何對同一件事達成一致
· tech · 約 7 分鐘 · 📚 Google SRE 讀書筆記 #14
一群機器要對「同一件事」達成一致——誰是 leader?這把鎖在誰手上?最新的值是多少?——聽起來很簡單,卻是分散式系統最難的問題之一。難在哪?因為機器會掛、網路會斷、時鐘不可信,而你要在這些前提下,…
負載平衡:先選對機房,再選對機器
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #13
一個請求從使用者送出到被處理,其實要通過兩層負載平衡,回答兩個不同層次的問題:去哪個資料中心? 進了之後分給哪台機器? 這兩層顧的事情完全不同,把它們分開看,負載平衡就清楚多了。 前端這層要處理的是「…
自動化、發布工程與簡單性:讓『改變』又快又安全
· tech · 約 5 分鐘 · 📚 Google SRE 讀書筆記 #12
自動化、發布工程、簡單性,乍看是三個不相干的主題。但把它們擺在一起,會發現它們在回答同一個問題:怎麼讓「變更」既快又不出事?SRE 的三招答案分別是——用機器一致地做、把上線做成可重現的流程、以及讓要…
資料管線與資料完整性:有備份不等於能還原
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #11
一個資料系統的可靠度,除了前面講的「服務不掛」,還有一層更根本的東西——資料本身不能不見、不能錯。這篇講兩件事:資料管線的可靠度,以及一個會顛覆你直覺的觀念:「有備份」不等於「能還原」。 資料管線(p…
連鎖失效與過載:別讓一台倒下拖垮全部
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #10
第一篇說可靠度的目標是「出錯也能運作」。但有一種故障特別難纏,因為它會自我放大:一個小問題引發骨牌,幾分鐘內把整個系統拖垮——這就是連鎖失效(cascading failure)。它最可怕的地方,是系…
為可靠度測試:測試不是證明沒 bug,是讓你敢快
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #9
這篇講一個常被當成「開發的事」、其實是可靠度基石的東西:測試。關鍵觀念先講:可靠度不是靠「不改」得來的——你一定得改(修 bug、加功能、換設定),而每次改動都是一場賭。測試的意義,就是把這場賭變成有…
事件應變:大事故真正的敵人是混亂
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #8
前面你學會了 on-call 止血、也學會了系統化除錯——但那是「一個人對付一個問題」。當一場大事故爆發(多人捲入、影響大、時間壓力高),你會發現最大的敵人往往不是技術問題本身,而是混亂。 技術問題總…
DevOps vs SRE:一個是介面,一個是實作
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #1.5
前一篇講完 SRE 是什麼,順手補一個超常被問、但其實是假問題的比較:「DevOps 和 SRE 有什麼不同?要選哪個?」之所以是假問題,是因為兩者根本不在同一層。Google 用一句很工程師的話破了…
Blameless Postmortem:把故障變成組織的學習
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #7
上一篇講怎麼找到 root cause——但找到之後呢?Postmortem(事後檢討) 就是把一次昂貴的故障,轉化成整個組織的學習:記錄發生什麼、影響多大、時間軸、真因、怎麼修的、怎麼防止再發生。而…
有效除錯:除錯是方法,不是天分
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #6
上一篇說 on-call 被叫到先止血;但止完血,總得找出為什麼。這篇講除錯——而它最重要的一個觀念是:除錯不是靠天分或運氣,是一套可以學的系統化方法。 新手和老手的差別,不在「知道答案」,而在有沒有…
告警與 On-call:什麼時候該把人吵醒
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #5
上一篇結尾留了一句:什麼時候該把人吵醒?這篇回答。它其實是兩件事:告警(什麼該響、響到誰)和 on-call(被叫到的人怎麼健康地扛)。核心觀念只有一句:告警的目的不是「通知」,是「該有人動手了」。 …
資料模型:關聯式、文件、圖,你在選什麼
· tech · 約 3 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #2
第一篇講了資料系統要追求什麼(可靠、可擴展、可維護)。這篇往下一層:你要用什麼「資料模型」來裝資料? 關聯式、文件、還是圖——這個選擇不是小事,它是你把現實映射成資料的底層抽象,決定了你怎麼建模、怎麼…
當 SQL 跑在 MPP 上:Greenplum 與 Cloudberry
· tech · 約 5 分鐘 · 📚 SQL 我以為我懂 #12
整個 SQL 系列的壓軸。前面 11 篇都跑在單機 PostgreSQL,這篇把同一批 SQL 放到 MPP(Massively Parallel Processing,大規模平行處理) 上——Gre…
交易與隔離層級:併發不打架的分級
· tech · 約 6 分鐘 · 📚 SQL 我以為我懂 #11
前面講的都是「一個查詢怎麼跑得快」(索引、EXPLAIN),這篇換個維度:很多交易同時跑,怎麼不互相打架? 這就是交易與隔離層級。(這裡講單機 PostgreSQL 的實務;分散式交易與一致性,交給姊…
讀懂 EXPLAIN:優化器到底怎麼跑你的 query
· tech · 約 3 分鐘 · 📚 SQL 我以為我懂 #10
上一篇留了一個問題:索引到底有沒有被用到?答案就在 EXPLAIN 裡。這篇是我之前寫的 Spark 執行計畫那篇的 SQL 版姊妹作——同一套「讀計畫、找瓶頸」的思維,換一個引擎。學會讀 EXPLA…
索引為什麼快 —— 也為什麼會失效
· tech · 約 2 分鐘 · 📚 SQL 我以為我懂 #9
接下來換個主題:引擎與效能。第一個要懂的就是索引——為什麼加了它查詢快幾百倍,又為什麼有時加了卻好像沒用。這兩個問題的答案,都藏在它的資料結構裡:B-tree。 沒有索引時,WHERE id = 50…
可靠、可擴展、可維護:資料系統的三個目標
· tech · 約 5 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #1
開一個新系列:讀 Martin Kleppmann 的 Designing Data-Intensive Applications(簡稱 DDIA)。它跟 FoDE 互補——FoDE 是資料工程的實務…
時間分桶與 SCD:SQL 處理時間的兩個坑
· tech · 約 3 分鐘 · 📚 SQL 我以為我懂 #8
接著上一篇的「區間」,這篇講時間在 SQL 裡的兩個坑——它們都源自同一件事:時間是連續的,但你的資料是離散的事件。 中間必然有「什麼都沒發生」的空隙,以及「值變了但你沒記」的變化。SQL 不會自動幫…
Gaps and Islands:把連續區間抓出來
· tech · 約 4 分鐘 · 📚 SQL 我以為我懂 #7
Window function 學會之後,這篇是它最漂亮的一個實戰。「連續登入幾天」「把連續的日期收成一段段區間」「找出序號的斷點」——這些看起來各不相同的需求,其實是同一個經典題:gaps and …
監控:四個黃金訊號
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #4
上一篇說 SLI 是量到的可靠度數字——而那些數字,就來自監控。但監控最容易走歪的地方,是把它當成「收集越多數字越好」,結果儀表板上一百個圖,真出事時反而找不到重點。這篇講 Google 給的精煉答案…
消除 Toil:把重複的維運當成待消滅的 bug
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #3
第一篇說 SRE 的內核是「維運可以被工程化」。這篇講的 toil,就是那個要被工程化掉的東西。很多人以為 toil 就是「辛苦的工作」,其實不是——它是一類有明確特徵的工作,而且如果你不主動砍它,它…
去重的正確姿勢:DISTINCT 不是唯一解
· tech · 約 4 分鐘 · 📚 SQL 我以為我懂 #6
資料重複幾乎是資料工程的日常:pipeline 重跑重複匯入、CDC 把同一筆的多個版本都撈進來、JOIN 的 fan-out 把列複製。很多人一講到去重就 DISTINCT——但去重根本不只 DIS…
Window Function:不收合的聚合
· tech · 約 4 分鐘 · 📚 SQL 我以為我懂 #5
上一篇的 GROUP BY 把每組收合成一列。但你一定遇過這種需求:「我想要整組的計算,又想保留每一列。」 例如——在每一筆訂單旁邊,標上它佔該客戶總額的比例;或在每個月的營收旁,標上跟上個月的差。收…
SLI / SLO / SLA:一個量測、一個目標、一個合約
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #2
上一篇說 error budget = 1 − SLO。但 SLO 是什麼?它跟另外兩個幾乎人人混用的縮寫——SLI、SLA——又差在哪?這三個字分不清,可靠度就無從談起。一句話先記住:SLI 是你「…
SRE 是什麼?從 Error Budget 講起
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #1
「SRE」這個詞很紅,但很常被誤解成「高級一點的維運」或「會寫程式的 SysAdmin」。讀完 Google 這本書我的體會是:它的靈魂根本不在職稱,而在一個轉念 + 一個機制——「100% 可靠不是…
GROUP BY:把多列收合成一列
· tech · 約 5 分鐘 · 📚 SQL 我以為我懂 #4
GROUP BY 每個人都會寫,但幾乎每個人也都被那句 column "..." must appear in the GROUP BY clause 擋過,而且常常搞不懂「我就選個欄位,為什麼不行?…
NULL 不是值,是「不知道」
· tech · 約 6 分鐘 · 📚 SQL 我以為我懂 #3
上一篇的 LEFT JOIN,會幫沒配到的列補上 NULL。那個 NULL 就是這篇的主角——它是無數 SQL bug 的源頭,而根本原因只有一句:NULL 不是一個值,是「不知道」。 一旦你把它讀成…
JOIN 的真相:先算笛卡爾積,再過濾
· tech · 約 6 分鐘 · 📚 SQL 我以為我懂 #2
上一篇把「你寫的順序不是它跑的順序」講清楚了。這篇用同一把鑰匙拆穿 JOIN。很多人把 JOIN 想成「把兩張表黏在一起」,然後死背 INNER/LEFT/RIGHT/FULL 各自的行為。但其實它們…
讀懂 Spark 執行計畫:.explain() 到底在說什麼
· tech · 約 5 分鐘 · 📚 Spark 學習筆記 #6
這個系列一路講下來,有兩句話反覆出現:「相信 Catalyst 最佳化器」、「打開 Spark UI 找瓶頸」。但我一直沒回答一個問題:你到底要怎麼看 Spark 做了什麼? 相信最佳化器不該是盲信—…
Service:擋在短命 Pod 前面的固定門牌
· tech · 約 5 分鐘 · 📚 Kubernetes 學習筆記 #4
第二篇留了一個問題:既然 Pod 是短命的、被換掉就有新的 IP,那別的服務要怎麼穩定找到它?你總不能把某顆 Pod 的 IP 寫死在設定裡——它下一秒可能就不在了。這篇的主角 Service,就是 …
你寫的 SQL 不是照你寫的順序跑
· tech · 約 4 分鐘 · 📚 SQL 我以為我懂 #1
你寫 SQL,幾乎都是 SELECT 開頭。寫久了很自然會以為:它就是從 SELECT 開始跑的。但不是——SQL 是宣告式的,你寫的是「要什麼」,引擎自己決定「怎麼跑、照什麼順序跑」,而它跑的順序跟…
資料工程的未來:工具會變、地基不變,讀《Fundamentals of Data Engineering》Ch.11(完結)
· tech · 約 3 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #11
十一章走到這裡,最後一個問題:資料工程的未來會長怎樣? 書的答案既讓人安心、又有點反直覺 —— 工具會一直變、而且越來越簡單;但底下那套生命週期與暗流,不會變。 這一篇,也是這個系列的完結。 這章把整…
Deployment 與自我修復:reconcile loop 的實戰
· tech · 約 6 分鐘 · 📚 Kubernetes 學習筆記 #3
第一篇給了靈魂(reconcile loop),第二篇給了原子(Pod)。但實務上你幾乎不會手動去建一個 Pod —— 你宣告的是 Deployment,而它正是 reconcile loop 最實用…
Pod、Node、Scheduler:Kubernetes 叢集的三個原子
· tech · 約 5 分鐘 · 📚 Kubernetes 學習筆記 #2
上一篇講了 K8s 的靈魂:你宣告期望,reconcile loop 不斷把現實拉過去。但那句「我要 3 個」——3 個什麼?落在哪台機器上?誰決定放哪? 這篇把叢集最基本的三個原子講清楚:Pod、N…
Kubernetes 是什麼:從「跑容器」到「宣告你要的狀態」
· tech · 約 5 分鐘 · 📚 Kubernetes 學習筆記 #1
很多人學 Kubernetes(K8s)覺得難,是因為一上來就被 kubectl、一堆 YAML 欄位、幾十種資源名詞淹沒。但其實 K8s 只有一個核心觀念,抓住它,後面全部都是同一句話的變形。這個系…
最該重視卻最被忽略的一章:安全與隱私,讀《Fundamentals of Data Engineering》Ch.10
· tech · 約 4 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #10
走完服務,生命週期還有一條貫穿全程的暗流沒單獨講:安全與隱私。書把它排在很後面,卻直說這是最重要、也最常被忽略的一章。而它最反直覺的第一句話是 —— 安全主要是「人」的問題,不是「工具」的問題。 大多…
資料的最後一哩:服務給分析與 ML,讀《Fundamentals of Data Engineering》Ch.9
· tech · 約 4 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #9
前面幾章一路走過源頭、儲存、擷取、建模 —— 但這些辛苦,只有在有人真的拿去用的那一刻才變現。這章講生命週期的最後一站:服務(Serving)。而它的第一原則,只有兩個字。 書把話講得很重:沒人會用他…
把資料變好用:查詢、建模與轉換,讀《Fundamentals of Data Engineering》Ch.8
· tech · 約 5 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #8
資料擷取進來、存好了,接下來的問題是:怎麼把它變成真正好用的東西? 這章給了三支柱 —— 查詢(Query)、建模(Modeling)、轉換(Transformation)。它們合起來,把「一堆原始資…
dbt 是什麼?用寫程式的方式做資料轉換
· tech · 約 5 分鐘
一句話:dbt(data build tool)是一個讓你「用一堆 SQL SELECT 把資料倉儲裡的原始資料,轉換成乾淨、可信、可重用的模型表」的框架 —— 而且把寫程式的紀律(版控、模組化、測試…
把資料搬進來:批次還是串流?讀《Fundamentals of Data Engineering》Ch.7
· tech · 約 5 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #7
源頭生出資料、儲存準備好接,中間那條把資料搬進來的動作,就是這章的主角:Ingestion(擷取)。它是生命週期的第二站,也是最多人一上來就糾結「要不要即時」的地方。這章最該先想清楚的一句話是 —— …
資料要存在哪:儲存的階層與抽象,讀《Fundamentals of Data Engineering》Ch.6
· tech · 約 7 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #6
上一篇講資料從源頭生出來。生出來之後第一件事就是:存去哪? 這章談儲存 —— 而它最反直覺的一點是:儲存不是「一個東西」,而是一整條從奈秒到小時、從天價到白菜價的階層。 看懂這條階層,後面所有「該放哪…
Airflow + Spark 跑在 K8s 上:不同的 node 怎麼跑不同的 pod
· tech · 約 11 分鐘 · 📚 Kubernetes 學習筆記 #8
Airflow 負責「什麼時候、用什麼順序」跑作業,Spark 負責「把大資料算完」。當這兩個東西都搬到 Kubernetes 上,最常見的困惑是:到底有哪些東西在跑、它們各自是不是一個 pod、又被…
資料從哪來:源頭系統與資料生成,讀《Fundamentals of Data Engineering》Ch.5
· tech · 約 6 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #5
前四章在講大方向 —— 生命週期、架構、選技術。從這章開始,書一階一階走進生命週期的每個環節。第一站是最前面、也最容易被工程師輕看的一段:資料到底是怎麼、在哪裡被生出來的? 這章最該記住的一句話是 —…
技術到底該怎麼選:讀《Fundamentals of Data Engineering》Ch.4
· tech · 約 5 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #4
上一篇講架構(why);這一章接著問:在那個架構底下,技術(how)到底該怎麼選? 這章最該先釘進腦袋的一句話是 —— 先有架構,才選技術,不是反過來。 工具是手段,被架構的取捨牽著走;一上來就問「要…
Structured Streaming 入門:把串流當成一張無界的表
· tech · 約 6 分鐘 · 📚 Spark 學習筆記 #5
前四篇都在講批次的 Spark —— 是什麼、DataFrame 實戰、shuffle 調校、怎麼跑起來。但資料不會等你湊成一批才來:訂單、點擊、日誌是持續流進來的。這篇講 Spark 處理串流的方式…
好的資料架構怎麼設計:讀《Fundamentals of Data Engineering》Ch.3
· tech · 約 4 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #3
上一篇給了生命週期的全貌(資料在做什麼);這一章問的是 —— 怎麼把承載它的系統設計得「好」? 這章最反直覺、也最該記住的一句話是:好的架構不是一張固定的藍圖,而是一個「用權衡換取彈性與可逆」的決策過…
Airflow 複雜流程控制:branching、trigger rules、TaskGroup、動態任務
· tech · 約 5 分鐘 · 📚 Airflow 學習筆記 #6
到目前為止,我們的 DAG 都是「固定的幾個 task、照線跑完」。但真實流程沒這麼乖:有時要依條件走不同分支、某個 task 失敗了清理工作還是得跑、幾十個相似 task 要收整齊、甚至執行期才知道…
資料工程生命週期:讀《Fundamentals of Data Engineering》Ch.2
· tech · 約 4 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #2
上一篇給了定義,這一章給的是全書的骨架 —— 資料工程生命週期(data engineering lifecycle)。這本書最有價值的貢獻,就是用這個框架把「資料工程在做什麼」講清楚:五個階段 + …
資料工程是什麼:讀《Fundamentals of Data Engineering》Ch.1
· tech · 約 4 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #1
我開一個新系列,讀 Joe Reis 與 Matt Housley 的 Fundamentals of Data Engineering。這本書最大的價值,是把「資料工程」這個常被講得很模糊的職能,收…
先確認痛點,再上重武器
· tech · 約 2 分鐘
這是一篇概念筆記 —— 一個我反覆在用的判斷,獨立成篇,讓其他文章可以連回來。 一句話:在引入任何重型工具或架構之前,先確認你的痛點真的到了需要它的量級。 沒到,就別上 —— 因為重武器的成本不在「裝…
Kafka 維運與部署:KRaft、retention/compaction 與監控
· tech · 約 7 分鐘 · 📚 Kafka 學習筆記 #5
前四篇講的是「Kafka 怎麼用」—— 可重播的 log、核心模型、投遞保證、生態系。這篇收尾,換個視角:當 Kafka 真的上線、要長期穩定跑,維運面得懂哪些事?四塊 —— KRaft(叢集怎麼管自…
Kafka 生態系:Connect、Schema Registry 與 Streams
· tech · 約 8 分鐘 · 📚 Kafka 學習筆記 #4
前三篇都在講 Kafka broker 本身 —— 可重播的 log、核心模型、投遞保證。但真實世界裡你幾乎不會「只用 broker」:資料要從別的系統搬進來、事件的長相要有人管、流上還得做轉換與聚合…
Airflow 怎麼連外部系統:Provider、Operator、Hook、Sensor
· tech · 約 6 分鐘 · 📚 Airflow 學習筆記 #5
前面幾篇都在講 Airflow 的內部機制 —— 排程、任務間傳資料。但真正的 pipeline 一定得碰外面的世界:查一個資料庫、丟檔案到 S3、打一支 HTTP API、等一個檔案到齊。這篇講 A…
Kafka 的投遞保證:acks、ISR 與 at-least-once / exactly-once
· tech · 約 8 分鐘 · 📚 Kafka 學習筆記 #3
第二篇講完事件「怎麼擺、誰來讀」,留了一個更尖銳的問題:崩潰重啟後,一筆事件到底會被重複處理、還是漏掉?這篇把 Kafka 的可靠性講透 —— acks、複本與 ISR、commit 時機,以及 at…
Kafka 的核心模型:Topic、Partition、Offset 與 Consumer Group
· tech · 約 6 分鐘 · 📚 Kafka 學習筆記 #2
第一篇把 Kafka 的心智模型定成一句話:一條可重播的事件 log。但那條 log 實際上怎麼擺、怎麼平行化、一群消費者又怎麼分工?這篇把 Kafka 的四個核心名詞講透 —— Topic、Part…
Apache Kafka 是什麼?從訊息佇列到事件串流
· tech · 約 4 分鐘 · 📚 Kafka 學習筆記 #1
一句話:Apache Kafka 是一個分散式的「事件串流平台」—— 它把系統之間流動的事件,以 High-throughput、可持久化、可重播的 log 形式集中起來,讓很多生產者一直寫、很多消費…
把 Spark 跑起來:從本機到叢集與 managed 平台
· tech · 約 6 分鐘 · 📚 Spark 學習筆記 #4
前三篇都在講 Spark 怎麼寫、怎麼跑得快(是什麼、DataFrame 實戰、shuffle 調校)。但同一段程式碼,在你筆電上跑、跟在一個幾十台機器的叢集上跑,中間到底發生什麼事?這篇講 runt…
Medallion 架構:用 Bronze / Silver / Gold 分層管資料品質
· tech · 約 5 分鐘
一句話:Medallion(獎牌)架構是一種把資料按「品質與精煉程度」分成三層的設計慣例 —— Bronze(原始)、Silver(清洗)、Gold(商業)—— 資料一層一層往上洗,愈往上愈乾淨、愈貼…
Airflow 任務間怎麼傳資料:XCom、TaskFlow 進階與 params
· tech · 約 4 分鐘 · 📚 Airflow 學習筆記 #4
上一篇講完排程,這篇處理一個很實際的問題:一個 task 算出來的東西,怎麼交給下一個 task? Airflow 的答案是 XCom,而 TaskFlow 把它包得幾乎看不見。順帶也講 params…
Spark 效能的本體:shuffle 與調校
· tech · 約 4 分鐘 · 📚 Spark 學習筆記 #3
第一篇和 上一篇都丟下同一句結論:Spark 的效能本體就是 shuffle。這篇把它講透 —— 為什麼 shuffle 貴、它怎麼把作業切成 stage,以及四個實際能少 shuffle、跑更快的手…
Spark DataFrame 實戰:讀取、轉換、寫出與 Spark SQL
· tech · 約 4 分鐘 · 📚 Spark 學習筆記 #2
上一篇把 Spark 的概念講完了:Driver / Executor、分區、惰性求值、shuffle。這篇動手用 DataFrame 實際轉一份資料 —— 讀進來、清洗、彙總、寫出去,並看看 Spa…
Airflow 排程的真相:data interval、catchup 與 backfill
· tech · 約 5 分鐘 · 📚 Airflow 學習筆記 #3
上一篇我們把 DAG 跑起來了,還特別把 catchup 設成 False「保平安」。這篇就來拆解 Airflow 最反直覺、也最多人卡住的部分:排程到底怎麼運作。搞懂這一段,你才真的會用 Airfl…
跑起第一個 Airflow:Docker 環境 + 你的第一個 DAG
· tech · 約 4 分鐘 · 📚 Airflow 學習筆記 #2
上一篇把 Airflow 的概念與架構講清楚了;這篇動手把它在本機跑起來,寫出第一個 DAG,並在 Web UI 上看著它跑完。目標很單純:從零到「我親眼看到自己的 DAG 在介面上變綠」。 方式 指…
Apache Airflow 是什麼?從 cron 到工作流程編排
· tech · 約 6 分鐘 · 📚 Airflow 學習筆記 #1
一句話:Apache Airflow 是用 Python 把「一連串有相依關係、要定時執行、失敗要能重試與監控」的工作編排起來的工具。它最初由 Airbnb 在 2014 年開發,現在是 Apache…
Apache Spark 是什麼?一篇搞懂分散式資料處理
· tech · 約 5 分鐘 · 📚 Spark 學習筆記 #1
一句話:Apache Spark 是一個把「大到單台機器裝不下、算不完」的資料,切成很多份、分散到一整個叢集上平行運算的引擎。它源自 UC Berkeley(2009),2014 成為 Apache …
領導力 - 用日記看見自己
· tech · 約 2 分鐘 · 📚 成為 Tech Leader 讀書筆記 #6
上一篇談到，「看不到自己」是創新的第一道障礙——你改不掉一個你沒看見的東西。作者給的解法意外地簡單：每天花五分鐘寫日記。而且最有意思的是，光是「開始寫」這個動作本身，就能同時訓練與觀察好幾件事。 聽到…
領導力 - 創新的三大障礙
· tech · 約 2 分鐘 · 📚 成為 Tech Leader 讀書筆記 #5
創新不是少數天才的靈光，而是一種「環境允許你提出不同想法」的能力（呼應 MOI 裡的 Innovation）。但有三種心態會在源頭就把創新擋下來——而且它們往往是無意識的。 第一道牆是看不清自己的行為…
領導力 - 成為 Leader 的迷思與痛苦
· tech · 約 3 分鐘 · 📚 成為 Tech Leader 讀書筆記 #4
在真正成為 Leader 之前，有些想法會先把自己擋在門外。 很多人抱著「不在其位、不謀其政」的心態，認為只有頭銜掛著 Leader 的人才有資格管事。問題是，抱這種心態的人真的當上 Leader 之…
領導力 - 成長模型
· tech · 約 3 分鐘 · 📚 成為 Tech Leader 讀書筆記 #3
成長模型描述的是「技能隨時間怎麼變化」。同一條成長曲線，在不同的觀察尺度下，會呈現完全不同的形狀。下面從最遠的宏觀、一路拉近到最貼近真實的微觀。 只要每天持續進步，把時間尺度拉得夠遠來看，技能的成長速…
領導力 - MOI
· tech · 約 5 分鐘 · 📚 成為 Tech Leader 讀書筆記 #2
領導方式模型就是透過幾項指標來描述一個環境，MOI模型就是其中一種描述方式 MOI 模型包含三個構面：Motivation（激勵）、Organization（組織）、Innovation（創新）。每個…
領導力
· tech · 約 3 分鐘 · 📚 成為 Tech Leader 讀書筆記 #1
「Leadership」這個詞常被誤解成「職位高」、「會下命令」、「有人聽話」——但實際上，Leadership的核心並不是權力或控制，而是影響力。 Leadership應該有其影響範圍，每個人在不同…
程式抽籤被質疑黑箱該如何處理
· tech · 約 5 分鐘
前陣子幫目前社區實作了一個簡單的車位抽籤頁面，後來其他管理委員們認為可能會被住戶質疑這程式不可信任，可能有黑箱疑慮，藉此研究了一下如何證明這個抽籤流程沒有黑箱。 - 複雜的說是抽籤的過程可受某方控制達…