Tech

你以為的安全 每天都有備份 ✓✓✓ 「帳面上」很安全 真的要還原時… 真出事時翻車 備份檔本身壞了(從沒驗過) 還原程序沒人跑過 → 手忙腳亂 還原太慢 → 超過 SLA、資料回不來 沒演練過還原的備份 = 薛丁格的備份(不打開不知道死活) 重要的不是「備份」,是「恢復」—— 備份只是達到恢復的手段

資料管線與資料完整性:有備份不等於能還原

· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #11

一個資料系統的可靠度,除了前面講的「服務不掛」,還有一層更根本的東西——資料本身不能不見、不能錯。這篇講兩件事:資料管線的可靠度,以及一個會顛覆你直覺的觀念:「有備份」不等於「能還原」。 資料管線(p…

#sre#data-engineering

一台倒下 → 流量轉移壓垮下一台 → 骨牌式全滅 Server A先過載 → 倒 ✗ Server B接手 A 流量 → 也倒 ✗ Server C全壓過來 → 倒 ✗ 而 retry storm(重試風暴)火上加油: 請求失敗 / 變慢 客戶端重試 總負載更高 正回饋:越失敗 → 越重試 → 越失敗(自我放大)

連鎖失效與過載:別讓一台倒下拖垮全部

· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #10

第一篇說可靠度的目標是「出錯也能運作」。但有一種故障特別難纏,因為它會自我放大:一個小問題引發骨牌,幾分鐘內把整個系統拖垮——這就是連鎖失效(cascading failure)。它最可怕的地方,是系…

#sre#reliability

E2E Integration Unit ↑ 少、慢、脆(像使用者走完整路徑) 元件兜起來(service + DB…) ↓ 多、快、穩(測單一函式) 倒過來(一堆 E2E、少 unit)= 反模式:慢、flaky、出事還難定位到哪層

為可靠度測試:測試不是證明沒 bug,是讓你敢快

· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #9

這篇講一個常被當成「開發的事」、其實是可靠度基石的東西:測試。關鍵觀念先講:可靠度不是靠「不改」得來的——你一定得改(修 bug、加功能、換設定),而每次改動都是一場賭。測試的意義,就是把這場賭變成有…

#sre#reliability

沒有指揮:混亂 系統故障中 工程 工程 工程 工程 搶著改、互相踩、資訊亂飛 → 修更慢 有指揮:有序 IC(統籌) Ops 修 Comms 報 Scribe 記 系統故障中 一人一角、資訊集中 → 修更快

事件應變:大事故真正的敵人是混亂

· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #8

前面你學會了 on-call 止血、也學會了系統化除錯——但那是「一個人對付一個問題」。當一場大事故爆發(多人捲入、影響大、時間壓力高),你會發現最大的敵人往往不是技術問題本身,而是混亂。 技術問題總…

#sre#incident

interface DevOps ← 哲學/文化:定義「該做什麼」 減少 silo · 接受失敗為常態 · 逐步變更 · 量測一切 · 自動化 implements(給出具體做法) class SRE implements DevOps ← 怎麼做 error budget · blameless postmortem · canary · SLI/SLO · 消除 toil DevOps 是方向與原則,SRE 是一個具體實作——不是二選一,是不同層次

DevOps vs SRE:一個是介面,一個是實作

· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #1.5

前一篇講完 SRE 是什麼,順手補一個超常被問、但其實是假問題的比較:「DevOps 和 SRE 有什麼不同?要選哪個?」之所以是假問題,是因為兩者根本不在同一層。Google 用一句很工程師的話破了…

#sre#culture

究責文化 · 惡性循環 出事 「誰的錯?」找戰犯 大家隱藏錯誤、不敢說真話 學不到 → 重蹈覆轍 Blameless · 良性循環 出事 「系統為何允許?」 大家坦白說出全貌 改系統 → 越來越穩 同一場故障,問「誰」還是問「系統」,把團隊帶向相反的兩個循環

Blameless Postmortem:把故障變成組織的學習

· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #7

上一篇講怎麼找到 root cause——但找到之後呢?Postmortem(事後檢討) 就是把一次昂貴的故障,轉化成整個組織的學習:記錄發生什麼、影響多大、時間軸、真因、怎麼修的、怎麼防止再發生。而…

#sre#culture

① Triage 止血 先讓系統活著 (別急著找 root cause) ② Examine 觀察 看監控 / log 四個黃金訊號 ③ Diagnose 診斷 假設 → 測試 → 排除 二分逼近 ④ Treat 修復 一次改一個變因 可回復 沒好?回頭再提假設 每一步都在「縮小範圍」;而反模式(亂猜、隨機換零件、一次改一堆)從不縮小,只是碰運氣

有效除錯:除錯是方法,不是天分

· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #6

上一篇說 on-call 被叫到先止血;但止完血,總得找出為什麼。這篇講除錯——而它最重要的一個觀念是:除錯不是靠天分或運氣,是一套可以學的系統化方法。 新手和老手的差別,不在「知道答案」,而在有沒有…

#sre#incident

一個告警進來:需要人嗎?多急? Page 呼叫 需要人「立刻」介入,否則使用者正在受影響 → 把人吵醒 Ticket 工單 需要人處理,但不急 → 上班時間看 Log 記錄 不需要人看,存著備查 / 事後分析 → 不打擾任何人 把不夠急的都塞進 Page → 告警疲勞、狼來了,真的出事反而被忽略

告警與 On-call:什麼時候該把人吵醒

· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #5

上一篇結尾留了一句:什麼時候該把人吵醒?這篇回答。它其實是兩件事:告警(什麼該響、響到誰)和 on-call(被叫到的人怎麼健康地扛)。核心觀念只有一句:告警的目的不是「通知」,是「該有人動手了」。 …

#sre#incident

關聯式 Relational users orders FK 表 + 外鍵,SQL 查 多對多、join 強 文件 Document 姓名、email 經歷 [ … ](巢狀) 學歷 [ … ](巢狀) 巢狀 JSON,一對多自然 局部性好(讀一次拿整份) 圖 Graph 節點 + 邊,高度連結 關係本身是主角

資料模型:關聯式、文件、圖,你在選什麼

· tech · 約 3 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #2

第一篇講了資料系統要追求什麼(可靠、可擴展、可維護)。這篇往下一層:你要用什麼「資料模型」來裝資料? 關聯式、文件、還是圖——這個選擇不是小事,它是你把現實映射成資料的底層抽象,決定了你怎麼建模、怎麼…

#distributed-systems#book-notes#data-modeling

Coordinator 收 query、規劃、分派 Segment 1 Segment 2 Segment 3 DISTRIBUTED BY (分佈鍵):用 hash(分佈鍵) 決定每列落哪個 segment,查詢在每台平行跑 ⚠ 分佈鍵不均勻 → 某 segment 資料爆多(skew),平行失效、最慢那台拖垮全部

當 SQL 跑在 MPP 上:Greenplum 與 Cloudberry

· tech · 約 5 分鐘 · 📚 SQL 我以為我懂 #12

整個 SQL 系列的壓軸。前面 11 篇都跑在單機 PostgreSQL,這篇把同一批 SQL 放到 MPP(Massively Parallel Processing,大規模平行處理) 上——Gre…

#sql#data-engineering

① Dirty Read 髒讀 T1 T2 餘額改 200(未提交) 讀到餘額 200 ❌ ROLLBACK ② Non-repeatable Read 不可重複讀 T1 T2 讀餘額 100 餘額改 200 並提交 又讀餘額 200 ❌ ③ Phantom Read 幻讀 T1 T2 查到 3 筆訂單 插入 1 筆符合訂單並提交 又查到 4 筆 ❌ 時間 →

交易與隔離層級:併發不打架的分級

· tech · 約 6 分鐘 · 📚 SQL 我以為我懂 #11

前面講的都是「一個查詢怎麼跑得快」(索引、EXPLAIN),這篇換個維度:很多交易同時跑,怎麼不互相打架? 這就是交易與隔離層級。(這裡講單機 PostgreSQL 的實務;分散式交易與一致性,交給姊…

#sql#concept

Nested Loop 外 外 外 內表(有索引更快) 外表每列 → 查內表一次 適合:小表 / 內表有索引 Hash Join 小表 Hash 表(記憶體) 大表 小表建 hash,大表 probe 適合:大表、等值 join Merge Join 1 3 5 2 4 6 兩側排序後,像拉鍊合併 適合:已排序 / 有索引

讀懂 EXPLAIN:優化器到底怎麼跑你的 query

· tech · 約 3 分鐘 · 📚 SQL 我以為我懂 #10

上一篇留了一個問題:索引到底有沒有被用到?答案就在 EXPLAIN 裡。這篇是我之前寫的 Spark 執行計畫那篇的 SQL 版姊妹作——同一套「讀計畫、找瓶頸」的思維,換一個引擎。學會讀 EXPLA…

#sql#performance

沒索引:Seq Scan(全表掃) 列 1 列 2 列 3 列 4 列 5 ← 目標 列 6 逐列掃過才找到 → O(n),資料越多越慢 有索引:B-tree 根 節點 節點 葉 葉 目標 葉 沿樹往下幾步就到 → O(log n)

索引為什麼快 —— 也為什麼會失效

· tech · 約 2 分鐘 · 📚 SQL 我以為我懂 #9

接下來換個主題:引擎與效能。第一個要懂的就是索引——為什麼加了它查詢快幾百倍,又為什麼有時加了卻好像沒用。這兩個問題的答案,都藏在它的資料結構裡:B-tree。 沒有索引時,WHERE id = 50…

#sql#performance

Reliability 可靠 出錯也能正常運作 · 容錯,不是無錯 · fault ≠ failure · 主動製造故障來測 硬體 / 軟體 / 人為錯誤 Scalability 可擴展 負載增加也扛得住 · 先描述「負載長相」 · 用 percentile 看效能 · scale up vs scale out 加機器前,先懂負載 Maintainability 可維護 讓人好好在上面工作 · Operability 好維運 · Simplicity 少意外複雜 · Evolvability 易演進 複雜的代價是別人來付 三個「非功能需求」——功能決定能不能用,這三個決定長期活不活得下去

可靠、可擴展、可維護:資料系統的三個目標

· tech · 約 5 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #1

開一個新系列:讀 Martin Kleppmann 的 Designing Data-Intensive Applications(簡稱 DDIA)。它跟 FoDE 互補——FoDE 是資料工程的實務…

#distributed-systems#book-notes

直接 GROUP BY date_trunc 日期筆數 7/013 7/025 7/03 沒這列 ✗ 7/042 補洞 generate_series + COALESCE 0 7/013 7/025 7/030 7/042 GROUP BY 只產出「有資料」的桶 —— 沒訂單的 7/03 整列消失,時間序列就斷了

時間分桶與 SCD:SQL 處理時間的兩個坑

· tech · 約 3 分鐘 · 📚 SQL 我以為我懂 #8

接著上一篇的「區間」,這篇講時間在 SQL 裡的兩個坑——它們都源自同一件事:時間是連續的,但你的資料是離散的事件。 中間必然有「什麼都沒發生」的空隙,以及「值變了但你沒記」的變化。SQL 不會自動幫…

#sql#data-engineering

你的服務 ① Latency 延遲 請求要多久才回? 分開看「成功」與「失敗」的延遲 ② Traffic 流量 系統現在多忙? QPS / 每秒請求數 ③ Errors 錯誤 多少請求失敗了? 失敗率(含「回 200 但內容是錯的」) ④ Saturation 飽和度 離極限還有多近? 資源用了幾成 → 最能預警 前三個 = 使用者體感(可直接當 SLI);第四個「飽和度」= 還能撐多久的預警

監控:四個黃金訊號

· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #4

上一篇說 SLI 是量到的可靠度數字——而那些數字,就來自監控。但監控最容易走歪的地方,是把它當成「收集越多數字越好」,結果儀表板上一百個圖,真出事時反而找不到重點。這篇講 Google 給的精煉答案…

#sre#monitoring

是不是 toil?看這六個特徵 ✓手動 —— 要人一步步動手做 ✓重複 —— 做過很多次、之後還會再做 ✓可自動化 —— 機器能做,只是還沒有人去寫 ✓無長期價值 —— 做完,系統並沒有變得更好 ✓隨規模線性成長 —— 服務變大,它就跟著變多 ✓被動反應 —— 被觸發才做,不是主動規劃出來的 符合越多 → 越是 toil。注意:開會、規劃、寫文件是 overhead,不算 toil

消除 Toil:把重複的維運當成待消滅的 bug

· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #3

第一篇說 SRE 的內核是「維運可以被工程化」。這篇講的 toil,就是那個要被工程化掉的東西。很多人以為 toil 就是「辛苦的工作」,其實不是——它是一類有明確特徵的工作,而且如果你不主動砍它,它…

#sre#reliability

① 完全相同的列 (1, A, 100) (1, A, 100) (1, A, 100) DISTINCT (1, A, 100) 整列一模一樣 → 去掉多的 DISTINCT / GROUP BY 就能解 ② 同一 key、多筆版本 user1 · 待付 · 2/01 user1 · 已付 · 2/03 user1 · 退款 · 2/05 ROW_NUMBER 留最新 user1 · 退款 · 2/05 列不相同 → DISTINCT 沒用 要挑「代表」那一筆

去重的正確姿勢:DISTINCT 不是唯一解

· tech · 約 4 分鐘 · 📚 SQL 我以為我懂 #6

資料重複幾乎是資料工程的日常:pipeline 重跑重複匯入、CDC 把同一筆的多個版本都撈進來、JOIN 的 fan-out 把列複製。很多人一講到去重就 DISTINCT——但去重根本不只 DIS…

#sql#data-engineering

輸入(orders):4 列 A · 100 A · 250 B · 80 B · 120 GROUP BY(收合) A · SUM 350 B · SUM 200 4 列 → 2 列(每組收成一列) SUM() OVER(不收合) A · 100組計 350 A · 250組計 350 B · 80組計 200 B · 120組計 200 4 列 → 4 列(每列多一欄看整組的值)

Window Function:不收合的聚合

· tech · 約 4 分鐘 · 📚 SQL 我以為我懂 #5

上一篇的 GROUP BY 把每組收合成一列。但你一定遇過這種需求:「我想要整組的計算,又想保留每一列。」 例如——在每一筆訂單旁邊,標上它佔該客戶總額的比例;或在每個月的營收旁,標上跟上個月的差。收…

#sql#concept